Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re^4: Module::Install hacking

by bulk88 (Priest)
on Sep 14, 2012 at 19:51 UTC ( #993787=note: print w/replies, xml ) Need Help??

in reply to Re^3: Module::Install hacking
in thread Module::Install hacking

BrowserUk established that the crash was occurring in the libgcc_s_dw2-1.dll ... and that piece of information made the job of fixing the problem so much easier.

Most of my ppm packages have a dependency on libgcc_s_dw2-1.dll, so I therefore distribute that file with them.
However, I don't like the idea of installing that dll into a path folder (which is where it needs to go) - given that there could well be other instances of that dll elsewhere in the path, thereby causing some incompatibility. So, I rename a copy of libgcc_s_dw2-1.dll to libgcc_sis_452.dll, have the module look for that dll instead, and distribute (in blib/script of the ppm package) libgcc_sis_452.dll instead of libgcc_s_dw2-1.dll. (I also take a similar approach with libstdc++-6.dll which I've renamed to cpp+-6_sis.dll, but I distribute that file only with the few packages that actually need it.)

I guess because of the crash that BrowserUk identified (details of which are not posted in this thread), the question of ABI comes up. I dont have copy of libgcc_s_dw2-1.dll in my Strawberry Perl folder, but I found libgcc_s_sjlj-1.dll. I think it is identical to libgcc_s_dw2-1.dll. Here are its exports.
_Unwind_Backtrace _Unwind_DeleteException _Unwind_FindEnclosingFunction _Unwind_Find_FDE _Unwind_GetCFA _Unwind_GetDataRelBase _Unwind_GetGR _Unwind_GetIP _Unwind_GetIPInfo _Unwind_GetLanguageSpecificData _Unwind_GetRegionStart _Unwind_GetTextRelBase _Unwind_SetGR _Unwind_SetIP _Unwind_SjLj_ForcedUnwind _Unwind_SjLj_RaiseException _Unwind_SjLj_Register _Unwind_SjLj_Resume _Unwind_SjLj_Resume_or_Rethrow _Unwind_SjLj_Unregister __absvdi2 __absvsi2 __absvti2 __addvdi3 __addvsi3 __addvti3 __ashlti3 __ashrti3 __bswapdi2 __bswapsi2 __clear_cache __clzdi2 __clzti2 __cmpti2 __ctzdi2 __ctzti2 __deregister_frame __deregister_frame_info __deregister_frame_info_bases __divdc3 __divsc3 __divti3 __divxc3 __emutls_get_address __emutls_register_common __enable_execute_stack __ffsdi2 __ffsti2 __fixdfti __fixsfti __fixunsdfdi __fixunsdfti __fixunssfdi __fixunssfti __fixunsxfdi __fixunsxfti __fixxfti __floattidf __floattisf __floattixf __floatuntidf __floatuntisf __floatuntixf __gcc_personality_sj0 __lshrti3 __modti3 __muldc3 __mulsc3 __multi3 __mulvdi3 __mulvsi3 __mulvti3 __mulxc3 __negti2 __negvdi2 __negvsi2 __negvti2 __paritydi2 __parityti2 __popcountdi2 __popcountti2 __powidf2 __powisf2 __powixf2 __register_frame __register_frame_info __register_frame_info_bases __register_frame_info_table __register_frame_info_table_bases __register_frame_table __subvdi3 __subvsi3 __subvti3 __ucmpti2 __udivmodti4 __udivti3 __umodti3 TlsCallback_0 TlsCallback_1 DllEntryPoint
Looks like it implements non-CPU-native math, and it implements GCC's C++ compliant exception handling. AFAIK, GCC's exception handling is not SEH/MS compliant. Note, I dont know the details on the post preprocessor or asm level of GCC exception handling. The question is, will the 2 different libgcc DLLs every try to pass a struct to each other, or use the same TLS slot, use the same Kernel32 Event, or see each other, or not see each other, for example, this line is MS DLL dependent, it lives in libgcc

Replies are listed 'Best First'.
Re^5: Module::Install hacking
by syphilis (Chancellor) on Sep 15, 2012 at 04:19 UTC
    (details of which are not posted in this thread)

    Not many details to report - it was just one of those "perl.exe has stopped working" type of messages as the program (ie any program that had loaded Gtk2-WebKit) was exiting.
    I don't know the exact details of what was going wrong, but both libgcc_sis_452.dll and libgcc_s_dw2-1.dll (which were identical) had been loaded by different parts of the program. Restructuring so that libgcc_sis_452.dll was used throughout fixed the problem.

    My guess is that, during exit of "the program", a handle was being thrown to the wrong dll.

    NOTE: The 2 dlls were not actually identical, but were close enough to identical. I did replace libgcc_s_dw2-1.dll with a copy that *was* identical to libgcc_sis_452.dll and it made no difference.

      Not many details to report

      The guts of the problem was an unhandled exception during the cleanup of g++ exception stack frames. Beyond that I did not have the appropriate MinGW symbol files to trace into.

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      RIP Neil Armstrong

        So ABI breakage and DLL hell between different builds of Mingw/GCC. Well what else could it be after looking at libgcc dll's export table other than GCC exception handling? div by zero or x87 FP exception? :-) I really really wish Mingw would has MS compatible SEH. Writing Win32 compiler-portable Perl XS/C code around bad C code beyond my control using IsBadReadPtr/IsBadWritePtr is cumbersome and those 2 will never catch STATUS_ILLEGAL_INSTRUCTION for example.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://993787]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2018-03-19 23:04 GMT
Find Nodes?
    Voting Booth?
    When I think of a mole I think of:

    Results (246 votes). Check out past polls.