Hi, Fresh msys/mingw (GCC 4.5.0), just installed. Fresh SVN revision of MPlayer, just downloaded. YASM added. Everything compiles fine, but the linking takes forever and never finishes. I tried waiting 2 hours on a very, very fast system. 2% CPU usage by ld.exe, 100MB/s writing to mplayer.exe and... nothing. I tried on my old msys/mingw 100% working configuration first (GCC 3.x.x) and the result was the same. I attach config.log, gzipped. Any ideas? I'm trying for 6 hours and I have no success so far.
On Thu, 25 Nov 2010 15:36:55 +0200, Georgi Petrov wrote:
Hi,
Fresh msys/mingw (GCC 4.5.0), just installed. Fresh SVN revision of MPlayer, just downloaded. YASM added. Everything compiles fine, but the linking takes forever and never finishes. I tried waiting 2 hours on a very, very fast system. 2% CPU usage by ld.exe, 100MB/s writing to mplayer.exe and... nothing. I tried on my old msys/mingw 100% working configuration first (GCC 3.x.x) and the result was the same.
I attach config.log, gzipped.
Any ideas? I'm trying for 6 hours and I have no success so far.
what mingw setup did you use? i built a few days ago and it worked for me. i installed tdm-gcc mingw and mingw.org gcc 4.4.0 on top of it. -compn
Hi,
what mingw setup did you use?
I used the recommended way - the Automated MinGW Installer, or mingw-get. It downloads online all latest packages of MinGW and MSYS from 10.2010 and installs them. The resulting GCC is 4.5.0. I did this, because my previous MSYS/MinGW configuration (effective GCC 3.4.x) exhibited the same problem with MPlayer. Previous (one year ago) MPlayer svn checkouts worked just fine on the very same configuration. This is really, really strange. Tomorrow I will investigate further. I just wanted to know if this behavior is known and if I'm not trying to solve already solved problem.
i built a few days ago and it worked for me. i installed tdm-gcc mingw and mingw.org gcc 4.4.0 on top of it.
I didn't know about TDM-GCC. Looks nice. Tomorrow I'll test it and report the results. Greetings, Georgi
Hi, This is getting interesting. The very same configuration and tree links ok in Windows XP under VMware. However under Win 7 the linking never finishes... I'm investigating the issue further and will report after I find the cause.
16+ hours trying to fix this issue and counting... The problem is that in the linking phase ld.exe cycles forever. Using Sysinternals procmon I was able to detect that ld.exe writes the same bytes over and over again in mplayer.exe at the same offset. Things I've tried: * Win 7 compatibility settings for XP SP2 to various GNU toolchain executables (ld.exe, gcc.exe, collect2.exe and so on) * Admin permissions * Older mingw/msys (happens on GCC3 and GCC4, seems unrelated) * TDM-GCC (still the same problem) * Adding and/or removing every single ld parameters I could think of * Running the final linking command line without some libraries only to find that it is a general problem, not caused by any particular library. * Changing directory paths to the shortest possible (some problems in the past were fixed that way) * Many other small things I don't remember. It is very counter productive, because EVERY time it hangs, ld.exe can't be killed and it generates over 100MB/s trying to write into mplayer.exe. The process can't be killed Task Manager. Logging in/out doesn't help either. The only way to kill it is to restart the whole machine, otherwise it becomes unresponsive (too much HDD activity) otherwise. I've done more than 80 restarts in the last 2 days :( The same problem doesn't occur under XP in VMware. Working under XP isn't an option, because eventually I'll develop for DxVA/Win7. Compiling under XP running in VMware is too stupid and is not a solution for a project that will take half a year. If somebody has any idea, it will be welcome. So far I've worked 3 days and my productivity is close to zero.
On Sun, Nov 28, 2010 at 12:35:51PM +0200, Georgi Petrov wrote:
16+ hours trying to fix this issue and counting...
The problem is that in the linking phase ld.exe cycles forever. Using Sysinternals procmon I was able to detect that ld.exe writes the same bytes over and over again in mplayer.exe at the same offset.
Things I've tried: * Win 7 compatibility settings for XP SP2 to various GNU toolchain executables (ld.exe, gcc.exe, collect2.exe and so on) * Admin permissions * Older mingw/msys (happens on GCC3 and GCC4, seems unrelated) * TDM-GCC (still the same problem) * Adding and/or removing every single ld parameters I could think of * Running the final linking command line without some libraries only to find that it is a general problem, not caused by any particular library. * Changing directory paths to the shortest possible (some problems in the past were fixed that way) * Many other small things I don't remember.
It is very counter productive, because EVERY time it hangs, ld.exe can't be killed and it generates over 100MB/s trying to write into mplayer.exe. The process can't be killed Task Manager. Logging in/out doesn't help either. The only way to kill it is to restart the whole machine, otherwise it becomes unresponsive (too much HDD activity) otherwise.
I've done more than 80 restarts in the last 2 days :(
The same problem doesn't occur under XP in VMware. Working under XP isn't an option, because eventually I'll develop for DxVA/Win7. Compiling under XP running in VMware is too stupid and is not a solution for a project that will take half a year.
If somebody has any idea, it will be welcome. So far I've worked 3 days and my productivity is close to zero.
I don't have any windows system so I can't confirm your issue, but this may be related: http://www.mail-archive.com/debian-alpha@lists.debian.org/msg24306.html -- Clément B. Not sent from a jesusPhone.
I don't have any windows system so I can't confirm your issue, but this may be related:
http://www.mail-archive.com/debian-alpha@lists.debian.org/msg24306.html
I tried --no-relax and it didn't help. Thanks for pointing me to this thread, but it describes slightly different problem - ld taking 100% CPU while doing something different than my case. In my case ld.exe takes 1% CPU and enters completely pointless cycle of writing to mplayer.exe at maximum speed. I even leaved it one night long and in the morning it was still doing the same thing. I will continue my investigation.
On Sun, 28 Nov 2010 13:44:41 +0200, Georgi Petrov wrote:
I don't have any windows system so I can't confirm your issue, but this may be related:
http://www.mail-archive.com/debian-alpha@lists.debian.org/msg24306.html
I tried --no-relax and it didn't help. Thanks for pointing me to this thread, but it describes slightly different problem - ld taking 100% CPU while doing something different than my case.
In my case ld.exe takes 1% CPU and enters completely pointless cycle of writing to mplayer.exe at maximum speed. I even leaved it one night long and in the morning it was still doing the same thing.
I will continue my investigation.
did you disable superfetch/prefetch in w7? if not, try doing that. also disable any antivirus crapware (windows defender, etc) also turn off indexing on your hd but if all that fails, just use xp in vmware :P -compn
did you disable superfetch/prefetch in w7? if not, try doing that. also disable any antivirus crapware (windows defender, etc) also turn off indexing on your hd
I've disabled superfetch anyway, I've tried without antivirus (MSE), indexing is turned off. In short - every attempt so far have failed. Now I've installed Windows 7 in VMware and will continue the investigation "inside", so at least I don't have to restart my real computer after each failed attempt. I will write if I find something new or a (temporary) fix.
but if all that fails, just use xp in vmware :P
Well...
On Sun, 28 Nov 2010 15:32:16 +0200, Georgi Petrov wrote:
did you disable superfetch/prefetch in w7? if not, try doing that. also disable any antivirus crapware (windows defender, etc) also turn off indexing on your hd
I've disabled superfetch anyway, I've tried without antivirus (MSE), indexing is turned off.
In short - every attempt so far have failed.
Now I've installed Windows 7 in VMware and will continue the investigation "inside", so at least I don't have to restart my real computer after each failed attempt.
I will write if I find something new or a (temporary) fix.
but if all that fails, just use xp in vmware :P
Well...
i meant for compiling only. or even just the linking part. -compn
i meant for compiling only. or even just the linking part.
Yes, this my consideration as well. I'll build a small custom solution if I have to, but since I will work on this project for half a year in the future, VMware-less solution will be more than required. You understand how uncomfortable would be to have a full featured VMware with XP inside sitting in the background just for linking a couple of libraries in a binary :) I'll try to submit a bug report, but I'm not sure where. May be I should start from MinGW/MSYS guys? The interesting part is that this doesn't happen with older MPlayer SVN revisions. Somewhere, somehow this problem was triggered. Compiling without optimization (in order to produce different code in each library) doesn't make any difference, as well as any imaginable ld switch. I won't give up.
On Sun, Nov 28, 2010 at 04:01:28PM +0200, Georgi Petrov wrote:
i meant for compiling only. or even just the linking part.
Yes, this my consideration as well. I'll build a small custom solution if I have to, but since I will work on this project for half a year in the future, VMware-less solution will be more than required.
You understand how uncomfortable would be to have a full featured VMware with XP inside sitting in the background just for linking a couple of libraries in a binary :)
I'll try to submit a bug report, but I'm not sure where. May be I should start from MinGW/MSYS guys?
The interesting part is that this doesn't happen with older MPlayer SVN revisions. Somewhere, somehow this problem was triggered. Compiling without optimization (in order to produce different code in each library) doesn't make any difference, as well as any imaginable ld switch.
I won't give up.
This may sounds stupid but… have you tried with a w7 out of the box (just like you did with xp)? It seems strange to me that no one ever build MPlayer on w7. -- Clément B. Not sent from a jesusPhone.
This may sounds stupid but… have you tried with a w7 out of the box (just like you did with xp)? It seems strange to me that no one ever build MPlayer on w7.
If I understand right the question, by right out of the box you mean a fresh installation of Windows 7, without any applications that may interfere? If this is your question, yes. A fresh Windows 7 in VMware has the same problem as my daily Windows 7 installation. Confirmed a couple of minutes ago. Should be reproducible by everybody.
Hello Grigori, On 11/28/2010 03:01 PM, Georgi Petrov wrote:
The interesting part is that this doesn't happen with older MPlayer SVN revisions. Somewhere, somehow this problem was triggered. Compiling without optimization (in order to produce different code in each library) doesn't make any difference, as well as any imaginable ld switch.
Have you tried to find the exact svn revision that broke linking? Erik
On Sun, Nov 28, 2010 at 5:07 PM, Erik Auerswald <auerswal@unix-ag.uni-kl.de> wrote:
Hello Grigori,
On 11/28/2010 03:01 PM, Georgi Petrov wrote:
The interesting part is that this doesn't happen with older MPlayer SVN revisions. Somewhere, somehow this problem was triggered. Compiling without optimization (in order to produce different code in each library) doesn't make any difference, as well as any imaginable ld switch.
Have you tried to find the exact svn revision that broke linking?
No, I haven't. I think that this will be too much work without some type of automation. I might setup such automation testing, but it will require excessive amount of time with unclear result. Although one year old MPlayer tree doesn't have this problem, it's obvious that the problem is in the toolchain and not MPlayer itself.
Georgi Petrov <gogothebee <at> gmail.com> writes:
Have you tried to find the exact svn revision that broke linking?
No, I haven't.
I think that this will be too much work without some type of automation.
It is certainly by far the fastest method to solve your problem (and will not take a whole day, but a few hours at most). (Additionally, I expect it will improve your ld bug-report significantly.) Carl Eugen
On Sun, Nov 28, 2010 at 11:45 PM, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Georgi Petrov <gogothebee <at> gmail.com> writes:
Have you tried to find the exact svn revision that broke linking?
No, I haven't.
I think that this will be too much work without some type of automation.
It is certainly by far the fastest method to solve your problem (and will not take a whole day, but a few hours at most). (Additionally, I expect it will improve your ld bug-report significantly.)
Hi Carl,
From another perspective you might be right. It will take me several hours to set up the procedure, but it won't be 100% automated. I will have to learn some things I don't know now, but it is pretty doable.
Let me introduce my point why it might be useless. So far I've figured out that the success/failure of the linking process depends on the number of arguments to ld.exe. Or the sum (in bytes) of all object files. One of these two! Nothing else! Tommorow I'll be more specific. I have one particular test case, where the statement gcc -o mplayer.exe a.o b.o c.o is shortened (by means of .o files). The important part is that it is shortened by a pretty exact number of .o arguments. I've found the exact number of .o arguments which is the threshold between: 1) ld complaining that many functions are missing (because of the .o files I've removed) and exits cleanly 2) ld hangs It definitely took me some time :) In my particular example I have behavior 1, but If I add another random .o file, the behavior changes to 2. And it doesn't matter which .o file exactly I add. Or which .o file from the "hang-causing statement" list I change for another .o file. My point is that in some point of MPlayer development, the .o/.a list grew past some magic number and ld began hanging. As this .o/.a files list (or the sum of object files in bytes) grows constantly, if this is the root cause, it doesn't depend on MPlayer itself. I might just find he SVN version, which adds the fatal .o, .a or sum of object bytes, which triggers the behavior switch from clean linking to hanging. What do you guys think about my theory?
On 11/28/10 03:36 pm, Georgi Petrov wrote:
On Sun, Nov 28, 2010 at 11:45 PM, Carl Eugen Hoyos<cehoyos@ag.or.at> wrote:
Georgi Petrov<gogothebee<at> gmail.com> writes:
Have you tried to find the exact svn revision that broke linking?
No, I haven't.
I think that this will be too much work without some type of automation.
It is certainly by far the fastest method to solve your problem (and will not take a whole day, but a few hours at most). (Additionally, I expect it will improve your ld bug-report significantly.)
Hi Carl,
From another perspective you might be right. It will take me several hours to set up the procedure, but it won't be 100% automated. I will have to learn some things I don't know now, but it is pretty doable.
Let me introduce my point why it might be useless.
So far I've figured out that the success/failure of the linking process depends on the number of arguments to ld.exe. Or the sum (in bytes) of all object files. One of these two! Nothing else! Tommorow I'll be more specific.
I have one particular test case, where the statement
gcc -o mplayer.exe a.o b.o c.o
is shortened (by means of .o files). The important part is that it is shortened by a pretty exact number of .o arguments. I've found the exact number of .o arguments which is the threshold between:
1) ld complaining that many functions are missing (because of the .o files I've removed) and exits cleanly 2) ld hangs
It definitely took me some time :)
In my particular example I have behavior 1, but If I add another random .o file, the behavior changes to 2. And it doesn't matter which .o file exactly I add. Or which .o file from the "hang-causing statement" list I change for another .o file.
My point is that in some point of MPlayer development, the .o/.a list grew past some magic number and ld began hanging.
As this .o/.a files list (or the sum of object files in bytes) grows constantly, if this is the root cause, it doesn't depend on MPlayer itself. I might just find he SVN version, which adds the fatal .o, .a or sum of object bytes, which triggers the behavior switch from clean linking to hanging.
What do you guys think about my theory?
What about if you use wildcards, eg *.o *.a or use a response file? Response file has a @ prefix, eg @foo and one argument per line and invoked as ld @foo. I don't know if your build of ld supports either response files or wildcards. Dave
What about if you use wildcards, eg *.o *.a or use a response file? Response file has a @ prefix, eg @foo and one argument per line and invoked as ld @foo. I don't know if your build of ld supports either response files or wildcards. Dave
Hi Dave, Yes, I know about the response file syntax and unfortunately ld still hangs. This "trick" (or something similar) also doesn't work: cat arguments.txt | xargs gcc -o mplayer.exe After more investigation, now I'm sure - the number of arguments is irrelevant. The summarized bytes of object code are. If I remove only 3-4 big .a libraries, ld finishes with error. However, I have to remove many, many, many small .o files to achieve the same. This leaves only one conclusion - I have to compile MPlayer with the least possible code. Well, I tried. Hard. ./configure --yasm='' --disable-mencoder --disable-largefiles --disable-iconv --disable-langinfo --disable-tv --disable-smb --disable-vcd --disable-bluray --disable-dvdnav --disable-dvdread --disable-cdparanoia --disable-cddb --disable-inet6 --disable-ftp --disable-ass --disable-win32dll --disable-libvorbis --disable-speex --disable-faad-internal --disable-pnm --disable-gl --disable-vidix --disable-vidix-pcidb --disable-tremor-internal --disable-libdvdcss-internal --disable-dvdread-internal --disable-libmpeg2-internal --disable-yuv4mpeg --disable-md5sum --disable-tga --disable-decoder=aasc --disable-decoder=asv1 --disable-decoder=asv2 --disable-decoder=avs --disable-decoder=bmp --disable-decoder=cavs --disable-decoder=cinepak --disable-decoder=cljr --disable-decoder=cscd --disable-decoder=cyuv --disable-decoder=dca --disable-decoder=dsicinvideo --disable-decoder=dvvideo --disable-decoder=dxa --disable-decoder=eightbps --disable-decoder=ffv1 --disable-decoder=ffvhuff --disable-decoder=flashsv --disable-decoder=flic --disable-decoder=fourxm --disable-decoder=fraps --disable-decoder=gif --disable-decoder=h261 --disable-decoder=h263 --disable-decoder=h263i --disable-decoder=h263p --disable-decoder=h264 --disable-decoder=huffyuv --disable-decoder=idcin --disable-decoder=indeo2 --disable-decoder=indeo3 --disable-decoder=interplay_video --disable-decoder=jpegls --disable-decoder=kmvc --disable-decoder=ljpeg --disable-decoder=loco --disable-decoder=mdec --disable-decoder=mjpeg --disable-decoder=mjpegb --disable-decoder=mmvideo --disable-decoder=mpeg_xvmc --disable-decoder=mpeg1video --disable-decoder=mpeg2video --disable-decoder=mpeg4 --disable-decoder=mpegvideo --disable-decoder=msmpeg4v1 --disable-decoder=msmpeg4v2 --disable-decoder=msmpeg4v3 --disable-decoder=msrle --disable-decoder=msvideo1 --disable-decoder=mszh --disable-decoder=nuv --disable-decoder=pam --disable-decoder=pbm --disable-decoder=pgm --disable-decoder=pgmyuv --disable-decoder=png --disable-decoder=ppm --disable-decoder=qdraw --disable-decoder=qpeg --disable-decoder=qtrle --disable-decoder=rawvideo --disable-decoder=roq --disable-decoder=rpza --disable-decoder=rv10 --disable-decoder=rv20 --disable-decoder=smacker --disable-decoder=smc --disable-decoder=snow --disable-decoder=sp5x --disable-decoder=svq1 --disable-decoder=svq3 --disable-decoder=targa --disable-decoder=theora --disable-decoder=tiertexseqvideo --disable-decoder=tiff --disable-decoder=truemotion1 --disable-decoder=truemotion2 --disable-decoder=tscc --disable-decoder=ulti --disable-decoder=vc1 --disable-decoder=vcr1 --disable-decoder=vmdvideo --disable-decoder=vmnc --disable-decoder=vp3 --disable-decoder=vp5 --disable-decoder=vp6 --disable-decoder=vp6f --disable-decoder=vqa --disable-decoder=wmv1 --disable-decoder=wmv2 --disable-decoder=wmv3 --disable-decoder=wnv1 --disable-decoder=x264 --disable-decoder=xan_wc3 --disable-decoder=xl --disable-decoder=xvid --disable-decoder=zlib --disable-decoder=zmbv --disable-decoder=dvbsub --disable-decoder=dvdsub --disable-decoder=pcm_alaw --disable-decoder=pcm_mulaw --disable-decoder=pcm_s8 --disable-decoder=pcm_s16be --disable-decoder=pcm_s16le --disable-decoder=pcm_s24be --disable-decoder=pcm_s24daud --disable-decoder=pcm_s24le --disable-decoder=pcm_s32be --disable-decoder=pcm_s32le --disable-decoder=pcm_u8 --disable-decoder=pcm_u16be --disable-decoder=pcm_u16le --disable-decoder=pcm_u24be --disable-decoder=pcm_u24le --disable-decoder=pcm_u32be --disable-decoder=pcm_u32le --disable-decoder=interplay_dpcm --disable-decoder=roq_dpcm --disable-decoder=sol_dpcm --disable-decoder=xan_dpcm --disable-decoder=adpcm_4xm --disable-decoder=adpcm_adx --disable-decoder=adpcm_ct --disable-decoder=adpcm_ea --disable-decoder=adpcm_g726 --disable-decoder=adpcm_ima_dk3 --disable-decoder=adpcm_ima_dk4 --disable-decoder=adpcm_ima_qt --disable-decoder=adpcm_ima_smjpeg --disable-decoder=adpcm_ima_wav --disable-decoder=adpcm_ima_ws --disable-decoder=adpcm_ms --disable-decoder=adpcm_sbpro_2 --disable-decoder=adpcm_sbpro --disable-encoder=vorbis --disable-encoder=snow --disable-demuxer=lavf --disable-demuxer=mov It didn't work.
I wrote in the MinGW mailing list. I'll try to work with them on fixing this issue: http://thread.gmane.org/gmane.comp.gnu.mingw.user/34857
On Mon, 29 Nov 2010 16:25:10 +0200, Georgi Petrov wrote:
I wrote in the MinGW mailing list. I'll try to work with them on fixing this issue:
if i may ask a dumb question... does it work on vista and if yes, would you be interested in developing mplayer on that instead ? -compn
What about using a different linker until ld is fixed? I'd guess that the Microsoft linker would work and if you want to use open source there is the OpenWatcom linker, wlink.exe.
Is this possible at all? I will investigate this, for sure. I always thought that object files, produced by a certain compiler must be linked with linker from the same toolchain? I might be completely wrong, of course. I will try.
if i may ask a dumb question... does it work on vista and if yes, would you be interested in developing mplayer on that instead ?
If nothing, nothing else works, well, yes. And considering that linking under Vista works. I will have to install Vista in VMware and test the whole process. However, I'm willing to find another solution. Actually I'm not sure which is worse - having XP in VMware just for linking mplayer.exe or switching from Win7 to Vista as my daily OS. Both seem bad, although not completely impossible. After all I want to start developing as soon as possible, but in the same time I want to have a comfortable environment. I'm working win MinGW devs and I will try with another linker.
On Mon, Nov 29, 2010 at 10:46:05PM +0200, Georgi Petrov wrote:
What about using a different linker until ld is fixed? I'd guess that the Microsoft linker would work and if you want to use open source there is the OpenWatcom linker, wlink.exe.
Is this possible at all? I will investigate this, for sure. I always thought that object files, produced by a certain compiler must be linked with linker from the same toolchain? I might be completely wrong, of course. I will try.
There is no "same toolchain", binutils and gcc are different projects. There is some dependency but it doesn't matter usually for "ordinary" linking. Also latest cygwin with gcc-3 and -mno-cygwin builds MPlayer just fine on Windows 7 (and I have a hard time imagining how it could depend on the OS anyway).
On 11/29/10 12:46 pm, Georgi Petrov wrote:
Microsoft linker would work and if you want to use open source there is the OpenWatcom linker, wlink.exe. Is this possible at all? I will investigate this, for sure. I always
What about using a different linker until ld is fixed? I'd guess that the thought that object files, produced by a certain compiler must be linked with linker from the same toolchain? I might be completely wrong, of course. I will try.
On OS/2 we use ld for a.out and ilink (IBM linker) or wlink for OMF. One possible problem with a different linker is losing the debug stuff. Dave
Ok, I'm giving up. 1 week was enough. More than 30 hours with this issue and not even a single percent success. A friend of mine with Windows 7 x64 compiles and links the tree just fine. I thought that Windows 7 x64 may be the final answer. I installed it in VMware and linking failed. Next - my friend tried my VMware image with 32 bit Windows 7 and the compilation failed on his machine (having in mind that on his native Windows 7 x64 it succeeded)... We both don't have any explanation. This is insane!!! I can't seem to be able to compile MPlayer on cygwin after numerous failures and incomplete configure builds. 3 hours worth trying are enough. After another 4 hours spent with Open Watcom's compiler, which complained about a ton of things and finally after reading the by-alien-written user's manual, gave me an .exe file, which crashes on startup... That's enough. ld.exe from the U++ project, which was a drop-in replacement, supposed to fix a similar problem from 2006 produced another mplayer.exe, which crashes. Trying to compile older ld from older binutils under MinGW proved another bloody mistake. I don't have enough desire for experimenting with IBM's linker, given the pain I went through with the Witcom's one. Any more experiments with cygwin are highly undesirable and last, but not least - since almost nobody seems to be interested in compiling MPlayer on Windows 7, I'm a minority without any chance of finding a similar soul. I'm starting DxVA development from tomorrow by linking on VMware + XP, running in the background just for ld.exe :(
Problem "solved"!!! Please read the complete solution without VMware or anything like that. You will be surprised!!! When every attempt so far failed, I did set up a XP installation from inside VMware, which was going to compile/link MPlayer from a shared folder from the host (Windows 7). The host (Win 7) should provide a shared tree and the guest (XP) should access the tree and compile/link mplayer.exe. Let me remind you that ld.exe doesn't hang in XP. You can't imagine my surprise when linking hanged! Actually my Windows 7 "side" hanged and it was responsible only for providing MPlayer's tree as a directory share!!! Now the whole VMware process couldn't be killed, just like when running native ld.exe... I was in shock, because it didn't make sense. Using Sysinternals Process Monitor, I was able to isolate the very same problem when: 1) ld.exe in Windows 7 (in VMware or on my machine) hangs. 2) Windows 7 on my machine hangs while only providing a file share to the XP, trying to link from inside VMware. ld.exe doesn't hang. VMware's process (with XP and ld.exe inside) didn't hang. The NT kernel did!!! This is the stack from hanged ld.exe (and supposedly VMware's) process: ntdll.dll!KiFastSystemCallRet kernel32.dll!WriteFile+0x4e msvcrt.dll!fprintf+0x235 msvcrt.dll!write+0x73 msvcrt.dll!CIcos+0x248 msvcrt.dll!fscanf_s_l+0x68 msvcrt.dll!fseeki64+0x2a msvcrt.dll!fsetpos+0x3f ld.exe+0x96e09 ld.exe+0x34c1b ld.exe+0x400d1 ld.exe+0x2560a ld.exe+0x4f2ac ld.exe+0x50083 ld.exe+0x14543 ld.exe+0x134f1 ld.exe+0x10db ld.exe+0x1178 kernel32.dll!BaseThreadInitThunk+0x12 ntdll.dll!RtlInitializeExceptionChain+0x63 ntdll.dll!RtlInitializeExceptionChain+0x36 The "hanged call" is "KiFastSystemCallRet" in ntdll.dll! This explains why I can't kill ld.exe or VMware's process (with "hanged" ld.exe inside). They are waiting for the NT executive to finish a system call! This was jaw-dropping. Obviously XP's function call returned, but Windows 7's one hanged. In theory this means that I can host the tree in XP inside VMware or even Linux inside VMware and share it to my machine's Windows 7. Fortunately, a strange thought went through my head - what about the file system? Would the same bug in ntdll.dll happen on a FAT32 partition? So, I created one, copied the tree inside and.. guess what... It didn't hang. mplayer.exe was built. Yes, the tree compiles and links just fine on my Windows 7 (no VMware) on a FAT32 partition... This doesn't solve the problem itself, but "works for me". I guess that ld.exe's file write logic somehow triggers a bug in ntdll.dll under certain circumstances. This is only a speculation from my uneducated point of view. See the last few calls: ntdll.dll!KiFastSystemCallRet kernel32.dll!WriteFile+0x4e msvcrt.dll!fprintf+0x235 msvcrt.dll!write+0x73 MSVCRT's write function uses fprintf to write to a stream (file stream obviously), then we have kernel32.dll's WriteFile and finally ntdll.dll's hanging KiFastSystemCallRet. This is insane, but a proven fact. My problem is solved. Should I contact Microsoft and file something like a bug report?
On Mon, Dec 06, 2010 at 08:04:15PM +0200, Georgi Petrov wrote:
Should I contact Microsoft and file something like a bug report?
If it also happens without antivirus and similar stuff. At least the kernel-level developers at Microsoft are not very likely to miss such a critical bug (though I am not so sure about NTFS, they must have rewritten stuff and introduced quite a few bugs, I also have a NTFS partition at home that works fine on XP and Linux but Vista and 7 NTFS drivers claim the MFT is broken while scandisk claims everything is fine).
If it also happens without antivirus and similar stuff. At least the kernel-level developers at Microsoft are not very likely to miss such a critical bug (though I am not so sure about NTFS, they must have rewritten stuff and introduced quite a few bugs, I also have a NTFS partition at home that works fine on XP and Linux but Vista and 7 NTFS drivers claim the MFT is broken while scandisk claims everything is fine).
I tried uninstalling (not only disabling) Microsoft Security Essentials before and it made no difference. Never mind. I can start the development now. I will notify Microsoft about this issue.
On Mon, 6 Dec 2010 20:04:15 +0200, Georgi Petrov wrote:
ntdll.dll!KiFastSystemCallRet
i forgot to ask if you had any service packs/windowsupdates installed. -compn
On Mon, Dec 6, 2010 at 10:21 PM, compn <tempn@twmi.rr.com> wrote:
On Mon, 6 Dec 2010 20:04:15 +0200, Georgi Petrov wrote:
ntdll.dll!KiFastSystemCallRet
i forgot to ask if you had any service packs/windowsupdates installed.
My Windows 7 (where the problem exists) is fully patched. All latest patches are installed. The problem seems to be triggered by more factors since some people don't have this particular problem. Also I'm not entirely sure, but I think that the thread spends some time in KiFastSystemCallRet, then the syscall returns, but it is entered again. Using another Sysinternals tool, it seems like ld.exe is writing again and again at the same offset in mplayer.exe. Right now I don't have more time to investigate, but I'm filling a bug report to Microsoft and will help them find the problem.
On 11/29/10 05:12 am, Georgi Petrov wrote:
This "trick" (or something similar) also doesn't work:
cat arguments.txt | xargs gcc -o mplayer.exe
After more investigation, now I'm sure - the number of arguments is irrelevant. The summarized bytes of object code are. If I remove only 3-4 big .a libraries, ld finishes with error. However, I have to remove many, many, many small .o files to achieve the same.
This leaves only one conclusion - I have to compile MPlayer with the least possible code.
Well, I tried. Hard.
What about using a different linker until ld is fixed? I'd guess that the Microsoft linker would work and if you want to use open source there is the OpenWatcom linker, wlink.exe. Dave
participants (7)
-
Carl Eugen Hoyos -
Clément Bœsch -
compn -
Dave Yeo -
Erik Auerswald -
Georgi Petrov -
Reimar Döffinger