#130 32-bit EXE that runs fine on Vista64 but hangs up on WinXP

closed-fixed
nobody
None
5
2009-12-29
2009-11-04
kmx
No

Hi,

I have revealed this issue while trying to compile perl 5.11.1 with native 32-bit mingw-w64 compiler (gcc toolchain binaries provided by sezero - marked "20091101").

In the end we (main credits goes to sisyphus) managed to compile perl binaries with both native 32-bit and native 64-bit compiler.

The problem occurs with 32-bit perl.exe executable we have created
- perl.exe runs fine on 64-bit MS Windows Vista (SP1)
- perl.exe hangs up on 32-bit MS Windows XP (SP3)

I have ripped off the resulting perl.exe + some DLLs and put it here:
http://svn.ali.as/cpan/users/kmx/strawberry_gcc-toolchain/bug_perl-binary/32bit-gcc4-mingw-w64/

You can test it by:
- downloading: libgcc_s_sjlj-1.dll + perl511.dll + perl.exe
- launching: "perl.exe -V"

On Vista it prints an error (which means it works as expected):
Can't locate Config.pm in @INC (@INC contains: .).
BEGIN failed--compilation aborted.

On WinXP it hangs up.

When I try to run it in a debugger on WinXP it seems that at the point when perl.exe hangs up it has 2 threads running - both waiting inside some system DLLs (perhaps some raise condition, thread-unsafety issue or whatever else).

Any help would be appreciated as we obviously need to generated 32-bit perl.exe that runs not only on WinVista but also on WinXP (and hopefully Win2000).

Thanks for any hint.

--
kmx

Discussion

  • Kai Tietz

    Kai Tietz - 2009-11-10

    Hmm, in general I can't confirm this issue you described here. At office we use mingw-w64 to build applications for 32-bit too and we did not detect any special problems about XP there.
    So I assume it has something to do with code here. Could you possibly provide a small testcase of this, or provide a gdb backtrace of both threads (with source), so that we can help to analyze?

    Cheers,
    Kai

     
  •  kmx

    kmx - 2009-11-13

    Kai,

    thanks for your reply. I will try to prepare reasonable small failing demo and post it here.

    --
    kmx

     
  • drangon zhou

    drangon zhou - 2009-11-14

    I also met with this issue.
    I use the latest toolchain to cross compile ffmpeg, the produced 32bit ffmpeg.exe runs fine under WinXP x64, but runs blocked under 32bit WinXP.

    But my application that using wxWidgets library runs fine in both OS.

     
  • NightStrike

    NightStrike - 2009-11-14

    Drangon, can you find a reduced test case? Or run with gdb and give us some output?

     
  •  kmx

    kmx - 2009-12-01

    Hi,

    I am still not able to prepare a small failing demo but see attached gdb log - perhaps you can see something.

    --
    kmx

     
  •  kmx

    kmx - 2009-12-01

    gdb log

     
  • Kai Tietz

    Kai Tietz - 2009-12-15

    Hmm, this could be reasoned by the lseeki64 we had overridden in our libmingwex.a library. I recently removed those code and instead we are using now the lseeki64 provided by msvcrt.dll again.
    Could you verify, if this bug is solved? We had recently an similar failure-report on IRC, where also the msvcrt's read-locking on files seems to block for XP (not Vista), but this was solved by this patch, too.

    Cheers,
    Kai

     
  •  kmx

    kmx - 2009-12-16

    Hello Kai,

    I'll be happy to verify this issue with latest version.

    As I am still using sezero's toolchain+crt binaries (marked 20101101) I have to kindly ask him to build new ones (if sezero is reading this post please leave a message if it is possible). Or point me to some crt binaries I can just drop over the last sezero's binaries.

    Thanks.

    --
    kmx

     
  •  kmx

    kmx - 2009-12-29

    Hello Kai,

    I have tested this issue with latest binaries kindly provided by sezero (marked "20091224"). And the bug seems to be solved.

    Thanks a lot!

    --
    kmx

     
  • Kai Tietz

    Kai Tietz - 2009-12-29
    • status: open --> closed-fixed
     
  • Kai Tietz

    Kai Tietz - 2009-12-29

    Hello Kmx1,

    I am glad that the fix solved the issue. Thanks for testing it.

    So, I close this bug as resolved.

    Cheers,
    Kai

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks