[BCB] Die nervigen Exporte in erzeugten Programmen

[jbg]

Zitat von Olli:

Leider bekomme ich sofort eine Exception bei der ersten LIB-Datei. Hier der Stack-Backtrace:

Die OMF Lesefunktion des Tools ist ziemlich einfach gestrickt. Soll ja nur aus $A0 "Export Symbol (Borland)" ein $FF "Comment" machen.
Wahrscheinlich kommt da einfach nur ein OMF-Block, den ich nicht bedacht habe.

Auf welche LIB Datei hast du das Tool angewandt? Wenn ich das bei mir (morgen) testen kann, könnte ich das Tool anpassen. Alternativ kann ich dir den (Delphi) Quellcode des Tools auch zukommen lassen.

[Olli]

Hi,

angewandt habe ich es auf eine LIB von Komponenten, die wir hier selber (bzw. die Vorgaenger) gestrickt haben: "FPComponents.lib".

Der Code wuerde mich natuerlich unabhaengig davon interessieren. Wenn du ihn mir noch heute Nacht zuschickst (hier ist es erst 23:30) habe ich noch was zu tun. Und Delphi habe ich ohnehin nur zuhause ... wuerde dann die Korrektur zurueckschicken, so ich denn eine hingebogen bekommen. Adresse bspw. [e-mail]

Uebrigens, habe es gerade nochmal explizit mit einer anderen LIB-Datei probiert (diesmal VirtualTreesC6.lib) und bekomme prinzipiell den gleichen Stacktrace. Hast du es jemals mit BCB6 probiert?

Code:

ChildEBP RetAddr  Args to Child              
0012f79c 7c827cfb 77e76792 00000002 0012f930 ntdll!KiFastSystemCallRet
0012f7a0 77e76792 00000002 0012f930 00000001 ntdll!NtWaitForMultipleObjects+0xc
*** WARNING: Unable to verify checksum for C:\Program Files\Borland\CBuilder6\Bin\LibExportRemover.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files\Borland\CBuilder6\Bin\LibExportRemover.exe
0012fac0 00404380 0012fad0 7c828752 0012fe84 kernel32!UnhandledExceptionFilter+0x7c0
WARNING: Stack unwind information not available. Following frames may be wrong.
0012faec 7c828723 0012fe84 0012ffb4 0012fba4 LibExportRemover+0x4380
0012fb94 7c82863c 0012c000 0012fba4 00010007 ntdll!ExecuteHandler+0x24
0012fe74 77e4bee7 0012fe84 00c2a858 0eedfade ntdll!RtlRaiseException+0x3d
0012fed4 0041093b 0eedfade 00000001 00000007 kernel32!RaiseException+0x53
0012ff44 004107f9 00000000 00000012 0012ff90 LibExportRemover+0x1093b
0012ff6c 00410d86 00000012 00000080 00404e52 LibExportRemover+0x107f9
0012ff84 004113c3 00413214 0012ff9c 0041146b LibExportRemover+0x10d86
0012ffc0 77e6f23b 00000000 00000000 7ffd8000 LibExportRemover+0x113c3

Code:

0041092c a1c4f84000      mov     eax,dword ptr [LibExportRemover+0xf8c4 (0040f8c4)]
00410931 e8c69fffff      call    LibExportRemover+0xa8fc (0040a8fc)
00410936 e8d538ffff      call    LibExportRemover+0x4210 (00404210)
0041093b 8d4308          lea     eax,[ebx+8] [color=red]<--[/color]
0041093e 8bd6            mov     edx,esi

EBX ist in meinem Fall 0x12f7bc, was meiner Erfahrung nach eine Heapadresse sein muesste. Ich mache mal ne kleine Debugsession ohne Delphi. (Notgedrungen, bin hier noch im Buero und ohne Delphi )

Nachtrag 2: Das Problem scheint innerhalb einer Stream-Klasse zu liegen. Die Exception ist also womoeglich einfach nur durchgepfiffen und da nach dem Aufruf an 00410936 EIP auf 0041093b steht, wird das als Adresse der Exception angegeben. Man muesste wohl im Code nachschauen ob da irgendwo bspw. ein ungueltiges Dateioffset angefordert wird und deshalb eine Exception ausgeloest wird.

Nachtrag 3: Die Funktion LibExportRemover+0x4210 wird offenbar nach LibExportRemover+0xa8fc aufgerufen um zu ueberpruefen, "ob was anliegt". Jedenfalls hat diese Funktion (LibExportRemover+0x4210) eine ziemlich simple Logik, die nur danach entscheidet, ob in EAX Null oder ein anderer Wert steht.

Code:

.text:00404210 sub_404210 proc near                    ; CODE XREF: sub_406F88+19p
.text:00404210                                         ; sub_40AA3C+49j ...
.text:00404210 or      eax, eax
.text:00404212 jnz     short loc_40421E
.text:00404214 mov     eax, 216
.text:00404219 call    sub_4047A4
.text:0040421E ; ---------------------------------------------------------------------------
.text:0040421E
.text:0040421E loc_40421E:                             ; CODE XREF: sub_404210+2j
.text:0040421E pop     edx
.text:0040421F push    esp
.text:00404220 push    ebp
.text:00404221 push    edi
.text:00404222 push    esi
.text:00404223 push    ebx
.text:00404224 push    eax
.text:00404225 push    edx
.text:00404226 push    esp
.text:00404227 push    7
.text:00404229 push    1
.text:0040422B push    0EEDFADEh
.text:00404230 push    edx
.text:00404231 jmp     ds:dword_413014
.text:00404231 sub_404210 endp

... nach einem GREP durch die VCL stellt sich das als die Implementierung von _RaiseExcept heraus:

Delphi-Quellcode:

  { ->    EAX     Pointer to exception object     }
  {       [ESP]   Error address           }

Um es kurz zu machen, ich denke, dass der Fehler eine Delphi-Exception vom Typ EListError ist.

Nachtrag 4: Hat irgendwas mit der Verwendung einer THandleStream-Instanz zu tun.

[jbg]

Zitat von Olli:

Hast du es jemals mit BCB6 probiert?

Klar. Denn nur für BCB 6 habe ich es geschrieben. Ab C++Builder 2006 werden keine EXPDEF Symbole mehr in die Package-.lib Datei geschrieben.

Was mir ist aber gerade aufgefallen, dass LibExportRemover keine Pfade in den Parametern verträgt. Es kommt sonst zu einem "File not found" Fehler, der wegen des fehlenden Exception Handlings direkt durchgereicht wird.
Man muss also LibExportRemover in dem Verzeichnis aufrufen, in dem die .lib Datei liegt.

[Olli]

Das scheint dann auch der Grund zu sein. Ich schaue mir später an, wie ich das noch gelöst bekomme und schicke es dir dann wieder zu. Danke erstmal für deine Mühen.