Crash when using 9.2.0 forwarder DLL

[LewisR]

This has become a blocker for the ArcaOS 5.0.5 release.

The testcase involves Paul's MediaTomb 0.12.0 port, which relies on gcc442.dll. Attempting to start mediatomb.exe after the gcc 9.2.0 forwarders have been installed (libgcc-fwd-9.2.0) results in:

MediaTomb UPnP Server version 0.12.0 - http://mediatomb.cc/

===============================================================================
Copyright 2005-2008 Gena Batsyan, Sergey Bostandzhyan, Leonhard Wimmer.
MediaTomb is free software, covered by the GNU General Public License version 2

2020-05-06 16:54:43    INFO: Loading configuration from: /mediatomb/home/.mediatomb/config.xml
2020-05-06 16:54:43    INFO: Checking configuration...
terminate called after throwing an instance of 'zmm::Exception'
terminate called recursively

Killed by SIGABRT
pid=0x0043 ppid=0x0040 tid=0x0001 slot=0x0019 pri=0x0200 mc=0x0001 ps=0x0010
F:\MEDIATOMB\BIN\MEDIATOMB.EXE
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

Backleveling to libgcc-fwd-4.9.2.1 allows the program to start.

[dmik]

This looks like some binary C++ incompatibility. I'm pretty sure GCC guys don't care much about such huge version gaps so it's not necessarily our port's specialty. Is there a way to rebuild MediaTomb across GCC 9.2.0? If yes, this is the fastest and best solution here. If not, it might take quite a while to figure out those C++ bits.

[LewisR]

I'd have to ask Paul about the MediaTomb rebuild, however, this is likely a wider problem. IOW, I doubt that this MediaTomb build would be the only application built 10 years ago which would be affected. If a dump would be helpful, I can get that easily enough.

[dmik]

If you mean procdump — not really. It's C++, debugging it w/o semantic info is a nightmare. So far, it's the first crashing case and we have a number of other programs using old GCC 4 runtime which still work IIRC.

Anyway, please try to convince Paul to rebuild it. And also a link to the application binary would not hurt.

[LewisR]

Sorry; I should have realized about the semantic info problem (thinking out loud).

Meanwhile:

https://www.dropbox.com/s/5jiu08vaolc3bx4/mediatomb-svn-r2093-os2-20100425.zip?dl=0

Rebuilding here is not so much the issue as again, customers updating and finding their long-working software no longer works. So, while I agree that fresh builds with current libs would be ideal, from a practical standpoint, that is not always practical (or possible).

[dmik]

Yeah, but as in case of LIBC, this is the only failing case so far. Well, we also had crashes in AOO but in a different place (in some C++ code) and they were gone with rebuilding too. I understand your concern of course, but If you care about compatibility with really old software that much, it's better to just supply the old GCC/LIBC runtime then (and use something like LIBPATHSTRICT=T). Forwarders are always a fallback solution I would say. To be relied upon only when it's impossible to rebuild an application which is critical to have or such. Not this case either.

And you should also keep in mind that providing backward compatibility for an unspecified number of old applications is simply not possible because our LIBC has never had strict API specifications. So the best way to go here is solve problems as they arise (given that it's worth time/money wise).

[dmik]

OK, I had one guess which proved to be it. GCC442.DEF used to build this particular version of the forwarder DLL in libgcc-fwd-9.2.0 does not have export ordinals making symbols effectively exported by name. However, the real GCC442.DLL forwarder provided by libgcc-fwd-4.9.2.1 (and I assume the original GCC442.DLL the application was linked against) uses ordinals and also exports fewer symbols. And some of the last symbols come in a different order. Here's the original order and ordinals:

  "___udivmoddi4" @72
  "___umoddi3" @73
  "__alloca" @74
  "__Unwind_Backtrace" @75
  "__Unwind_Find_FDE" @76
  "__Unwind_ForcedUnwind" @77
  "__Unwind_GetIPInfo" @78

Here is the order and ordinals of the DLL from libgcc-fwd-9.2.0:

___udivmoddi4                      @72
___umoddi3                         @73
__alloca                           @74
__Unwind_Backtrace                 @75
__Unwind_DeleteException           @76
__Unwind_Find_FDE                  @77
__Unwind_FindEnclosingFunction     @78
__Unwind_ForcedUnwind              @79
__Unwind_GetCFA                    @80
__Unwind_GetDataRelBase            @81
__Unwind_GetGR                     @82
__Unwind_GetIP                     @83
__Unwind_GetIPInfo                 @84
__Unwind_GetLanguageSpecificData   @85
__Unwind_GetRegionStart            @86
__Unwind_GetTextRelBase            @87
__Unwind_RaiseException            @88
__Unwind_Resume_or_Rethrow         @89
__Unwind_Resume                    @90
__Unwind_SetGR                     @91
__Unwind_SetIP                     @92

As you may see, the original DLL exports __Unwind_Find_FDE under ordinal 76 while in the real 9.2.0 DLL OS/2 assigns it ordinal 77 and so on. Therefore, the application which imported these entries by ordinal ends up using wrong functions. Hence the crash.

Making the ordinals of the forwarder DLL in 9.2.0 match the forwarder DLL in 4.9.2 fixes the mediatomb crash here.

The current GCC 9.2.0 spec uses the same set of .DEF files for forwarders used by all GCC 4 specs including GCC 4.9.2. How come these .DEF files could be different from actual DLLs (that should have been built from them!) supplied by GCC 4.9.2 RPMs we should ask @ydario as it was him who released this RPM version 4.9.2 (4.9.2.1-3 to be exact) and all its forwarders.

I guess that Yuri realized that forwarders built from these .DEF files didn't match the originals (in terms of ordinals and such) and then fixed the forwarder DLLs but didn't update their .DEF files when putting them into the SRPM (where I took them from for the GCC 9.2.0 series).

Anyway, the fix is pretty straight forward. I will take real forwarders from libgcc-fwd-4.9.2.1-3.oc00.pentium4.rpm and use emximp to get their actual .DEF files and then rebuild GCC 9 RPMs. Stay tuned.

[ydario]

we should ask @ydario as it was him who released this RPM

you are asking too much for my memory! :-)

[dmik]

Rebuilt GCC (two archs took 5h 20m here BTW), uploading to repositories. Please wait for a couple of hours. Closing this.

[LewisR]

Confirmed working for the current testcase.

Thanks!

[LewisR]

Separate issue. New ticket.