Legacy Embarcadero Discussion Forums: Exception handling does not work in one ...

Welcome, Guest: Login; Guest Settings

Thread: Exception handling does not work in one project!

This question is answered. Helpful answers available: 2. Correct answers available: 1.

Reply to this Thread

Search Forum

Back to Thread List

	Replies: 21 - Last Post: Jul 6, 2017 9:37 AM Last Post By: Alex Belo

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Exception handling does not work in one project!

Posted: Jun 21, 2017 3:13 AM

exception , handling

Hello - I have again problems with the exception handling in C++Builder.

I am building for Win64 (clang compiler, VCL, Win 10, Tokyo) and I realized that exception handling is not working in one of my application.
So, i tested two other of my application - there it works.
Also in a blank new VCL application no problem - everything fine.

What I did:

I just added in all applications behind a button this code:

try
{
throw std::exception("Bad Boy!");
}
catch (const std::exception & ex)
{
Button1->Caption="Exception caught!";
}

As I said, there is one application where it does not work.
That means:
The exception is caught by another exception handler, not the one directly behind the try - so no crash.
I used the debugger in order to see what happens - but if I attach the debugger to the application - then no problem, the correct (first) catch is used.
Unfortunately without the debugger attached the application crashes at another location where a boost::thread_interrupted exception is thrown (this is my real problem).

So - what are possible reasons for a broken exception handling in an application?
Every hint is warmly welcome.

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project!

Posted: Jun 23, 2017 2:20 AM

in response to: Oliver Weinheimer

I found out that the global Application->OnException event is triggered before the first catch in the source code is executed.
Is there any way to change this untypical behavior?
What can lead to this behavior?

Remy Lebeau (Te...

Posts: 9,447
Registered: 12/23/01

Re: Exception handling does not work in one project!

Posted: Jun 23, 2017 11:42 AM

in response to: Oliver Weinheimer

Oliver Weinheimer wrote:
I found out that the global Application->OnException event is triggered before the first catch in the source code is executed.

That is not possible given the code you have shown.

For one thing, only Delphi-style exceptions derived from Sysutils::Exception (other than EAbort) can ever go through the OnException event. Not C++ exceptions, and certainly not STL/Boost exceptions. OnException is fired by the TApplication::HandleException() method, which requires a TObject as input, and its type is checked for Sysutils::Exception before firing OnException.

For another thing, OnException is only triggered for exceptions that are not caught in a catch/except block in user code, but are caught by various internal RTL exception handlers. For example, the one inside of TApplication.Run() when an uncaught exception is raised inside of a message handler. Or the ones that surround the TForm OnDestroy, OnShow, OnHide, and OnClose(Query) events. Just to name a few.

--
Remy Lebeau (TeamB)

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project!

Posted: Jun 24, 2017 5:20 PM

in response to: Remy Lebeau (Te...

I added this line to the constructor of the Form:

Application->OnException = AppException;

and also this function:

void __fastcall TDicomToolMainForm::AppException(TObject *Sender, Exception *E)
{
Application->ShowException(E);
ShowMessage("Foobar");
}

->
Foobar is displayed - so OnException is triggered! Or do I overlook something?
You are right that is should not happen - but it happens.
The code I showed is the code I added to the projects main form. Nothing else.
Just a Button with the try/catch and the AppException method.

I used first the autoupdated project file and then I added all source code files and libs to a new clean project file.
In both cases the exception handling is broken - no difference.

I will dig deeper into the problem at monday.

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project!

Posted: Jun 23, 2017 5:21 AM

in response to: Oliver Weinheimer

I added all source code files and libs to a new clean project file.
The broken exception handling still remains.

Can the strange behavior be triggered by ...
a) the project options?
b) one/some linked libraries?
c) preprocessor directives?
d) ???

What is a good way to find this out?

By the way:
- The exception handling in this project worked in earlier versions - the version compiled with C++Builder Berlin 10.1 Update 2 worked.
- I was able to make yesterday a debug version of the project where the exception handling worked - but after a rebuild it was again broken.
- Exception handling is broken for debug and release version - no problems if the debugger is attached to the debug version.
- Problems like this make me crazy

Edited by: Oliver Weinheimer on Jun 23, 2017 5:24 AM

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Exception handling does not work in one project! [Edit]

Posted: Jun 23, 2017 9:44 PM

in response to: Oliver Weinheimer

Oliver Weinheimer wrote:

What is a good way to find this out?

Stop on "try" in question, invoke CPU window, copy disassembled code,
post it here.

Also it would be nice to see the same code compiled in workable version
(in another project or even in previous CB version).

I hope some asm expert will find a difference...

If there is no difference then the problem is somewhere in
"std::exception("Bad Boy!")"...

Can the strange behavior be triggered by ...

Wrong path(s) or/and old libs/packages after autoupdate of the project.

BTW, is project autoupdated form previous version of CB?

--
Alex

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit]

Posted: Jun 24, 2017 5:23 PM

in response to: Alex Belo

Entire CPU window for working small test project until try:

00000000004058BF EBDC jmp TForm1::TForm1(System::Classes::TComponent*) + 0xad
00000000004058C1 F0428800 lock mov [rax],al
00000000004058C5 0000 add [rax],al
00000000004058C7 0000 add [rax],al
00000000004058C9 0F1F8000000000 nop dword ptr [rax+$00000000]
Unit1.cpp.21: void __fastcall TForm1::Button1Click(TObject *Sender)
00000000004058D0 4883EC78 sub rsp,$78
00000000004058D4 48894C2470 mov [rsp+$70],rcx
00000000004058D9 4889542468 mov [rsp+$68],rdx
00000000004058DE 488B4C2470 mov rcx,[rsp+$70]
00000000004058E3 BA08000000 mov edx,$00000008
Unit1.cpp.24: throw std::exception("Bad Boy!");
00000000004058E8 48894C2438 mov [rsp+$38],rcx
00000000004058ED 4889D1 mov rcx,rdx
00000000004058F0 E89B872A00 call __cxa_allocate_exception + 0x0
00000000004058F5 4889C1 mov rcx,rax
00000000004058F8 488D1581672B00 lea rdx,[rel $002b6781]
00000000004058FF 48894C2430 mov [rsp+$30],rcx
0000000000405904 4889C1 mov rcx,rax
0000000000405907 E8E4020000 call std::exception::exception(char const*) + 0x0
000000000040590C EB00 jmp TForm1::Button1Click(System::TObject*) + 0x3e

Entire CPU window for problem project until try:

yctGUIMainForm.cpp.4554: void __fastcall TDicomToolMainForm::JvDockServer1CustomPanel
0000000000BA9EB0 4883EC20 sub rsp,$20
0000000000BA9EB4 48894C2418 mov [rsp+$18],rcx
0000000000BA9EB9 4889542410 mov [rsp+$10],rdx
0000000000BA9EBE 4C89442408 mov [rsp+$08],r8
0000000000BA9EC3 4C890C24 mov [rsp],r9
0000000000BA9EC7 488B4C2418 mov rcx,[rsp+$18]
yctGUIMainForm.cpp.4557: AParent = PanelDock;
0000000000BA9ECC 488B89B0090000 mov rcx,[rcx+$000009b0]
0000000000BA9ED3 488B542408 mov rdx,[rsp+$08]
0000000000BA9ED8 48890A mov [rdx],rcx
yctGUIMainForm.cpp.4558: }
0000000000BA9EDB 4883C420 add rsp,$20
0000000000BA9EDF C3 ret
yctGUIMainForm.cpp.4561: void __fastcall TDicomToolMainForm::Button1Click(TObject * Sender)
0000000000BA9EE0 4881EC38020000 sub rsp,$0000000000000238
0000000000BA9EE7 48898C2430020000 mov [rsp+$0230],rcx
0000000000BA9EEF 4889942428020000 mov [rsp+$0228],rdx
0000000000BA9EF7 488B8C2430020000 mov rcx,[rsp+$0230]
0000000000BA9EFF BA08000000 mov edx,$00000008
yctGUIMainForm.cpp.4565: throw std::exception("Bad Boy!");
0000000000BA9F04 48898C24A0000000 mov [rsp+$00a0],rcx
0000000000BA9F0C 4889D1 mov rcx,rdx
0000000000BA9F0F E8DCB97801 call __cxa_allocate_exception + 0x0
0000000000BA9F14 4889C1 mov rcx,rax
0000000000BA9F17 488D1544007F01 lea rdx,[rel $017f0044]
0000000000BA9F1E 48898C2498000000 mov [rsp+$0098],rcx
0000000000BA9F26 4889C1 mov rcx,rax
0000000000BA9F29 E8B2AD8CFF call std::exception::exception(char const*) + 0x0
0000000000BA9F2E EB00 jmp TDicomToolMainForm::Button1Click(System::TObject*) + 0x50

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Exception handling does not work in one project! [Edit] [Edit]

Posted: Jun 24, 2017 11:11 PM

in response to: Oliver Weinheimer

Code looks the same in both cases.

OK, at least there is no blunder in binary code ...

But I can see only throw part and there is no code of catch clause
(after last jmp). Call of __cxa_throw must be somewhere below ...

(But taking into account that code works under debugger but glitches
without it I think the problem is not in generated code ... :-/)

catch (const std::exception & ex)

To find proper catch rtl must find type of object in catch().
Maybe type information is incorrect/broken ... Or you have more than
one copy of std::exception compiled independently (wild guesses) ...

Any chance that the test works in one form of the application and
glitches in another form?..

Entire CPU window

To copy needed part of CPU window select lines as usual (select first
line and use shift+down) an press Ctrl+C.

--
Alex

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit] [Edit]

Posted: Jun 26, 2017 8:33 AM

in response to: Alex Belo

a) I tested the exception code in some other forms of the problem project - same result - exception handling broken.

b) After this I worked some hours in another project, came back to my problem project and a simple "make" gave me an exe with working exception
handling for the debug settings, in the release version the exception handling remains broken.
After some changes in the source code (nothing related to the exception handling code) the exception handling was again broken for the debug build.
I copied the CPU window for the short-term working debug build and for the build with the again broken exception handling.
There is no difference to see - for my eyes, output see below .
Does that mean, that the compilation is Okay and there is a problem with the linker?

Entire CPU window for problem project (debug build, exception handling working):

yctGUIMainForm.cpp.4554: void __fastcall TDicomToolMainForm::JvDockServer1CustomPanel
0000000000BA9EC0 4883EC20 sub rsp,$20
0000000000BA9EC4 48894C2418 mov [rsp+$18],rcx
0000000000BA9EC9 4889542410 mov [rsp+$10],rdx
0000000000BA9ECE 4C89442408 mov [rsp+$08],r8
0000000000BA9ED3 4C890C24 mov [rsp],r9
0000000000BA9ED7 488B4C2418 mov rcx,[rsp+$18]
yctGUIMainForm.cpp.4557: AParent = PanelDock;
0000000000BA9EDC 488B89B0090000 mov rcx,[rcx+$000009b0]
0000000000BA9EE3 488B542408 mov rdx,[rsp+$08]
0000000000BA9EE8 48890A mov [rdx],rcx
yctGUIMainForm.cpp.4558: }
0000000000BA9EEB 4883C420 add rsp,$20
0000000000BA9EEF C3 ret
yctGUIMainForm.cpp.4561: void __fastcall TDicomToolMainForm::Button1Click(TObject * Sender)
0000000000BA9EF0 4881EC38020000 sub rsp,$0000000000000238
0000000000BA9EF7 48898C2430020000 mov [rsp+$0230],rcx
0000000000BA9EFF 4889942428020000 mov [rsp+$0228],rdx
0000000000BA9F07 488B8C2430020000 mov rcx,[rsp+$0230]
0000000000BA9F0F BA08000000 mov edx,$00000008
yctGUIMainForm.cpp.4565: throw std::exception("Bad Boy!");
0000000000BA9F14 48898C24A0000000 mov [rsp+$00a0],rcx
0000000000BA9F1C 4889D1 mov rcx,rdx
0000000000BA9F1F E8ECB5B300 call __cxa_allocate_exception + 0x0
0000000000BA9F24 4889C1 mov rcx,rax
0000000000BA9F27 488D1534007F01 lea rdx,[rel $017f0034]
0000000000BA9F2E 48898C2498000000 mov [rsp+$0098],rcx
0000000000BA9F36 4889C1 mov rcx,rax
0000000000BA9F39 E8B2AD8CFF call std::exception::exception(char const*) + 0x0
0000000000BA9F3E EB00 jmp TDicomToolMainForm::Button1Click(System::TObject*) + 0x50
0000000000BA9F40 488D15513EE801 lea rdx,[rel $01e83e51]
0000000000BA9F47 4C8D0542D8AF00 lea r8,[rel $00afd842]
0000000000BA9F4E 488B8C2498000000 mov rcx,[rsp+$0098]
0000000000BA9F56 E875B6B300 call __cxa_throw + 0x0
0000000000BA9F5B E957040000 jmp TDicomToolMainForm::Button1Click(System::TObject*) + 0x4c7
yctGUIMainForm.cpp.4567: catch (const std::exception & ex)
0000000000BA9F60 89D1 mov ecx,edx
0000000000BA9F62 4889842420020000 mov [rsp+$0220],rax
0000000000BA9F6A 898C241C020000 mov [rsp+$021c],ecx

Entire CPU window for problem project (debug build, exception handling broken):

yctGUIMainForm.cpp.4554: void __fastcall TDicomToolMainForm::JvDockServer1CustomPanel
0000000000BA9EB0 4883EC20 sub rsp,$20
0000000000BA9EB4 48894C2418 mov [rsp+$18],rcx
0000000000BA9EB9 4889542410 mov [rsp+$10],rdx
0000000000BA9EBE 4C89442408 mov [rsp+$08],r8
0000000000BA9EC3 4C890C24 mov [rsp],r9
0000000000BA9EC7 488B4C2418 mov rcx,[rsp+$18]
yctGUIMainForm.cpp.4557: AParent = PanelDock;
0000000000BA9ECC 488B89B0090000 mov rcx,[rcx+$000009b0]
0000000000BA9ED3 488B542408 mov rdx,[rsp+$08]
0000000000BA9ED8 48890A mov [rdx],rcx
yctGUIMainForm.cpp.4558: }
0000000000BA9EDB 4883C420 add rsp,$20
0000000000BA9EDF C3 ret
yctGUIMainForm.cpp.4561: void __fastcall TDicomToolMainForm::Button1Click(TObject * Sender)
0000000000BA9EE0 4881EC38020000 sub rsp,$0000000000000238
0000000000BA9EE7 48898C2430020000 mov [rsp+$0230],rcx
0000000000BA9EEF 4889942428020000 mov [rsp+$0228],rdx
0000000000BA9EF7 488B8C2430020000 mov rcx,[rsp+$0230]
0000000000BA9EFF BA08000000 mov edx,$00000008
yctGUIMainForm.cpp.4565: throw std::exception("Bad Boy!");
0000000000BA9F04 48898C24A0000000 mov [rsp+$00a0],rcx
0000000000BA9F0C 4889D1 mov rcx,rdx
0000000000BA9F0F E8DCB97801 call __cxa_allocate_exception + 0x0
0000000000BA9F14 4889C1 mov rcx,rax
0000000000BA9F17 488D1544007F01 lea rdx,[rel $017f0044]
0000000000BA9F1E 48898C2498000000 mov [rsp+$0098],rcx
0000000000BA9F26 4889C1 mov rcx,rax
0000000000BA9F29 E8B2AD8CFF call std::exception::exception(char const*) + 0x0
0000000000BA9F2E EB00 jmp TDicomToolMainForm::Button1Click(System::TObject*) + 0x50
0000000000BA9F30 488D15410B0D02 lea rdx,[rel $020d0b41]
0000000000BA9F37 4C8D0532DC7401 lea r8,[rel $0174dc32]
0000000000BA9F3E 488B8C2498000000 mov rcx,[rsp+$0098]
0000000000BA9F46 E865BA7801 call __cxa_throw + 0x0
0000000000BA9F4B E957040000 jmp TDicomToolMainForm::Button1Click(System::TObject*) + 0x4c7
yctGUIMainForm.cpp.4567: catch (const std::exception & ex)
0000000000BA9F50 89D1 mov ecx,edx
0000000000BA9F52 4889842420020000 mov [rsp+$0220],rax
0000000000BA9F5A 898C241C020000 mov [rsp+$021c],ecx

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Exception handling does not work in one project! [Edit] [Edit]

Posted: Jun 26, 2017 9:33 AM

in response to: Oliver Weinheimer

Oliver Weinheimer wrote:

At this stage only EMBT experts can help, I think ...

I copied the CPU
window for the short-term working debug build and for the build with
the again broken exception handling. There is no difference to see -
for my eyes

Yes, code (unfortunately incomplete again) is the same in both cases.

Does that mean, that the compilation is Okay and there is a problem
with the linker?

Most likely but who knows...

BTW, have you tried 32 bit version for testing? Also you can try
alternative linker for 32 bit version

Linking With Unilink
https://wiki.dlang.org/Linking_With_Unilink

ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0307.zip

Just rename ulink.exe to ilink32.exe and replace standard linker in bin
directory; it should work.

Also (I still use CB2007 so I don't know all details) you can try
"internal" (Integrated in IDE) and "external" (in separate process)
compilation: AFAIK sometimes results are different...

--
Alex

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit] [Edit]

Posted: Jun 27, 2017 4:49 AM

in response to: Alex Belo

Unilink is not an option because it is a very memory intensive image processing application - 64bit are needed.

To find proper catch rtl must find type of object in catch().
Maybe type information is incorrect/broken ... Or you have more than
one copy of std::exception compiled independently (wild guesses) ...

Can it be a problem if the project is compiled with -O3 and a static linked library with -O2 compiler setting? Should be no problem.

What can lead to incorrect/broken type information?

The project is linked to different static libs build with C++Builder and dlls build with C++Builder and MS Visual C++. All libs use static linking - so they include there own std::exception - right? I do not know anything about how the correct std::exception is searched if an exception is thrown. Is it possible that an exception is thrown in the main exe and the std::exception from a dll build with Visual C++ is used - which does not exactly fit to the catch in the main exe???

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Exception handling does not work in one project! [Edit] [Edit]

Posted: Jun 27, 2017 11:00 AM

in response to: Oliver Weinheimer

Oliver Weinheimer wrote:

Unilink is not an option because it is a very memory intensive image
processing application - 64bit are needed.

I mean to compile 32 bit version for testing only if it is possible.

Can it be a problem if the project is compiled with -O3 and a static
linked library with -O2 compiler setting?

There were various problems with optimization in the past (usually
wrong code generation) so why not ...

What can lead to incorrect/broken type information?

Oh, bugs are not predictable.

The project is linked to different static libs build with C++Builder
and dlls build with C++Builder and MS Visual C++. All libs use static
linking - so they include there own std::exception - right?

It depends.

Dll's can export type information so other modules in program (main exe
or/and other dlls) compiled with the same version of compiler can
import and use this info. In this case all such modules will use the
same binary code of exported class(es) and have the same type
information.

I do not know anything about how the correct std::exception is
searched if an exception is thrown.

C++ exception internals (some simple introduction)
http://seegive.blogspot.ru/2012/01/c-exception-internals.html

C++ exception handling internals (exploration in "hacker's style")
https://monoinfinito.wordpress.com/series/exception-handling-in-c/

Particularly: 16th chapter:
C++ exceptions under the hood: finding the right catch in a landing pad

Is it possible that an exception is thrown in
the main exe and the std::exception from a dll build with Visual C++
is used - which does not exactly fit to the catch in the main exe?

No, it should not...

more than one copy of std::exception compiled independently (wild
guesses) ...

This is my weak attempt to imagine how it can be but most likely this
is not right and real reason is bug in compiler or linker...

Have you tried building with external version of tools ("compile in
separate process" option AFAIK)? External versions usually are "more
correct"...

Also make sure that incremental link is disabled.
--
Alex

Edited by: Alex Belo on Jun 28, 2017 12:26 AM

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit] [Edit]

Posted: Jun 30, 2017 2:45 AM

in response to: Alex Belo

Yes, I tried this ...

Also make sure that incremental link is disabled.

and yes, I tried this.

Makes no difference - exception handling remains broken!

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit] [Edit]

Posted: Jun 30, 2017 8:41 AM

in response to: Oliver Weinheimer

Weekend!

Summary:

Problem project compiles and links fine with Tokyo - but exception handling is still broken - Tokyo release is is so frustrating. For me it is useless.

-> exception handling broken in one of my projects
-> I tested -O3 compiler options - at least in my tests no advantage against -02
-> Code folding is partly broken in different projects
-> Code Insight did not work since ages, never ever for me

Basic stuff is broken in Tokyo and it is more worse than Berlin or Seattle , I hope Embacadero will fix it in 10.2.1 ... but is there hope?
It costs me days/weeks to workaround new problems of new IDE releases, Do I have to do a complete reinstall for 10.2.1?

C++Builder needs bug fixes NO new features. That is my opinion.

By the way:
-> Simple editor features like "Code folding" or "Code Insight features" work like charm in Visual Studio or Notepad++ .

I have to decide after the weekend if I go back to Berlin and then push my working code step by step in VS C++ libraries.

Slàinte mhath

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Exception handling does not work in one project! [Edit] [Edit] [Edit]

Posted: Jun 30, 2017 10:29 AM

in response to: Oliver Weinheimer

Oliver Weinheimer wrote:

C++Builder needs bug fixes NO new features. That is my opinion.

"Tokyo has been pretty useless - PERIOD. Too many things broke it in.
Obviously adequate QA was not done on it before release."

(c) Remy Lebeau

https://forums.embarcadero.com/thread.jspa?messageID=891031&tstart=0#891031

--
Alex

P.S. I still use CB2007. Ask me why...

Rudy Velthuis (...

Posts: 7,731
Registered: 9/22/99

Re: Exception handling does not work in one project! [Edit] [Edit] [Edit]

Posted: Jun 30, 2017 10:54 PM

in response to: Alex Belo

Alex Belo wrote:

Oliver Weinheimer wrote:

C++Builder needs bug fixes NO new features. That is my opinion.

"Tokyo has been pretty useless - PERIOD.

Not for me, but I mainly use Delphi and don't program for Android. <g>

--
Rudy Velthuis http://www.rvelthuis.de

"We must all hear the universal call to like your neighbor like
you like to be liked yourself." -- George W. Bush

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit] [Edit] [Edit]

Posted: Jul 3, 2017 4:21 AM

in response to: Rudy Velthuis (...

Found the problem today.

The problem project links to more than 100 static and dynamic libraries.
My idea was that the broken exception handling is maybe caused by a library.
So I created a new blank project and added the libraries - one after the other and I tested the exception handling int the project after every lib addition.
Than after adding one specific dynamic library which encapsulates database activities exception handling was broken.
This library did not make any problem in earlier versions of the problem project.
It is a dll using the static version of the RTL - memmgr.a is added.
The functionality introduced by the lib is working but the lib breaks the exception handling in the complete project.

My workaround for now is that I add the source code of the dll directly to the problem project - and exception handling works again in my problem project!

The problem described here has probably also affected the problem in this thread:

https://forums.embarcadero.com/message.jspa?messageID=884921#884921

Thanks for all help and hints!

Edited by: Oliver Weinheimer on Jul 3, 2017 4:22 AM

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Exception handling does not work in one project! [Edit] [Edit] [Edit] [Edit]

Posted: Jul 3, 2017 9:19 AM

in response to: Oliver Weinheimer

Oliver Weinheimer wrote:

Found the problem today.

OK, good to know.

It is a dll using the
static version of the RTL - memmgr.a is added.

Hmm... But how it can affect other modules?..

What symbols does export/import the "wrong" dll?

Does linker show warnings? Try setting additional linker's command line
keys to see maximum information.

--
Alex

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit] [Edit] [Edit] [Edit]

Posted: Jul 4, 2017 4:02 AM

in response to: Alex Belo

No - the linker did not give warnings.

I am in contact with someone from embacardero - as soon as I know what was exactly the problem I will write an entry to this thread.

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit] [Edit] [Edit] [Edit]

Posted: Jul 6, 2017 5:33 AM

in response to: Oliver Weinheimer

linker , tokyo

After a few emails with a very helpful and nice staff of embacardero support he identified the problem - it is a bug in the linker.

The problem was a wrong linked lib/dll called yctDatabaseLib.a

His workaround:

1) if you remove library from the calling project in the "Project Manager"
2) and link to the library in the code as follows:
#pragma link "yctDatabaseLib.a"
OR
#pragma comment(lib,"yctDatabaseLib.a")

then it will work.

I tested this myself and it worked in my test

Here his explanation of the bug:

The reason is the link order, the calling EXE links to the exported debugger hook... in the DLL instead of the RTL and this causes the exception handling to execute differently as the exception handling code internally "looks"/uses the debugger symbol ("__CPPdebugHook") to report an exception.

The bug is reported - let us hope that it will be fixed.

Show can go on ...

Another Info I get:

The bug is marked for fixing in Tokyo update 1 ...

Alex Belo

Posts: 626
Registered: 10/8/06

Re: Exception handling does not work in one project! [Edit] [Edit] [Edit] [Edit] [Edit]

Posted: Jul 6, 2017 9:37 AM

in response to: Oliver Weinheimer

Oliver Weinheimer wrote:

After a few emails with a very helpful and nice staff of embacardero
support he identified the problem - it is a bug in the linker.

Thank you for information.

--
Alex

Oliver Weinheimer

Posts: 73
Registered: 8/20/04

Re: Exception handling does not work in one project! [Edit]

Posted: Jun 24, 2017 5:23 PM

in response to: Alex Belo

Call Stack in for working small test project until try:

:00000000004058e8 ; TForm1::Button1Click(System::TObject*)
:000000000050aa03 ; Vcl::Controls::TControl::Click()
:000000000052c19b ; Vcl::Stdctrls::TCustomButton::Click()
:000000000052d0c4 ; Vcl::Stdctrls::TCustomButton::CNCommand(Winapi::Messages::TWMCommand&)
:000000000040b9f5 ; System::TObject::Dispatch(void*)
:000000000050a2f0 ; Vcl::Controls::TControl::WndProc(Winapi::Messages::TMessage&)
:0000000000510ff8 ; Vcl::Controls::TWinControl::WndProc(Winapi::Messages::TMessage&)
:000000000052bbe5 ; Vcl::Stdctrls::TButtonControl::WndProc(Winapi::Messages::TMessage&)
:0000000000509de2 ; Vcl::Controls::TControl::Perform(unsigned int, unsigned long long, long long)
:00000000005111ee ; Vcl::Controls::DoControlMsg(HWND__*, void*)
:00000000005123a8 ; Vcl::Controls::TWinControl::WMCommand(Winapi::Messages::TWMCommand&)
:00000000005e1698 ; Vcl::Forms::TCustomForm::WMCommand(Winapi::Messages::TWMCommand&)
:000000000040b9f5 ; System::TObject::Dispatch(void*)
:000000000050a2f0 ; Vcl::Controls::TControl::WndProc(Winapi::Messages::TMessage&)
:0000000000510ff8 ; Vcl::Controls::TWinControl::WndProc(Winapi::Messages::TMessage&)
:00000000005dcb9c ; Vcl::Forms::TCustomForm::WndProc(Winapi::Messages::TMessage&)
:000000000068c3c8 ; Jvdockcontrolform::TJvDockBaseControl::WindowProc(Winapi::Messages::TMessage&)
:00000000006918e5 ; Jvdockcontrolform::TJvDockServer::WindowProc(Winapi::Messages::TMessage&)
:00000000005102bc ; Vcl::Controls::TWinControl::MainWndProc(Winapi::Messages::TMessage&)
:00000000004a4996 ; System::Classes::StdWndProc(HWND__*, unsigned int, unsigned long long, unsigned long long)
:00007FFE249ABC50 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AB80B ; C:\WINDOWS\System32\USER32.dll
:00007FFE01BDD765 ; C:\Program Files (x86)\TeamViewer\tv_x64.dll
:00007FFE249ABC50 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AB94C ; C:\WINDOWS\System32\USER32.dll
:00007FFE249C11F3 ; C:\WINDOWS\System32\USER32.dll
:00007FFE274A90B4 ; <UNKNOWN>
:00007FFE23DF1164 ; C:\WINDOWS\System32\win32u.dll
:00007FFE249AB060 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AAEE8 ; C:\WINDOWS\System32\USER32.dll
:00007FFE16B46194 ; C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.0_none_108e4f62dfe5d999\COMCTL32.DLL
:00007FFE16B74CE6 ; C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.0_none_108e4f62dfe5d999\COMCTL32.DLL
:00007FFE249ABC50 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AB80B ; C:\WINDOWS\System32\USER32.dll
:0000000000511187 ; Vcl::Controls::TWinControl::DefaultHandler(void*)
:000000000050b0ad ; Vcl::Controls::TControl::WMLButtonUp(Winapi::Messages::TWMMouse&)
:000000000040b9f5 ; System::TObject::Dispatch(void*)
:000000000050a2f0 ; Vcl::Controls::TControl::WndProc(Winapi::Messages::TMessage&)
:0000000000510ff8 ; Vcl::Controls::TWinControl::WndProc(Winapi::Messages::TMessage&)
:000000000052bbe5 ; Vcl::Stdctrls::TButtonControl::WndProc(Winapi::Messages::TMessage&)
:00000000005102bc ; Vcl::Controls::TWinControl::MainWndProc(Winapi::Messages::TMessage&)
:00000000004a4996 ; System::Classes::StdWndProc(HWND__*, unsigned int, unsigned long long, unsigned long long)
:00007FFE249ABC50 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AB5CF ; C:\WINDOWS\System32\USER32.dll
:00000000005eac93 ; Vcl::Forms::TApplication::ProcessMessage(tagMSG&)
:00000000005ead08 ; Vcl::Forms::TApplication::HandleMessage()
:00000000005eb156 ; Vcl::Forms::TApplication::Run()
:0000000000405157 ; wWinMain
:00000000006abbf8 ; _wstartup

Call Stack in problem project until try:

:0000000000ba9f04 ; TDicomToolMainForm::Button1Click(System::TObject*)
:0000000000cdab33 ; Vcl::Controls::TControl::Click()
:0000000000cfc32b ; Vcl::Stdctrls::TCustomButton::Click()
:0000000000cfd254 ; Vcl::Stdctrls::TCustomButton::CNCommand(Winapi::Messages::TWMCommand&)
:0000000000bbe745 ; System::TObject::Dispatch(void*)
:0000000000cda420 ; Vcl::Controls::TControl::WndProc(Winapi::Messages::TMessage&)
:0000000000ce1128 ; Vcl::Controls::TWinControl::WndProc(Winapi::Messages::TMessage&)
:0000000000cfbd75 ; Vcl::Stdctrls::TButtonControl::WndProc(Winapi::Messages::TMessage&)
:0000000000cd9f12 ; Vcl::Controls::TControl::Perform(unsigned int, unsigned long long, long long)
:0000000000ce131e ; Vcl::Controls::DoControlMsg(HWND__*, void*)
:0000000000ce24d8 ; Vcl::Controls::TWinControl::WMCommand(Winapi::Messages::TWMCommand&)
:0000000000bbe745 ; System::TObject::Dispatch(void*)
:0000000000cda420 ; Vcl::Controls::TControl::WndProc(Winapi::Messages::TMessage&)
:0000000000ce1128 ; Vcl::Controls::TWinControl::WndProc(Winapi::Messages::TMessage&)
:0000000000ce03ec ; Vcl::Controls::TWinControl::MainWndProc(Winapi::Messages::TMessage&)
:0000000000c62786 ; System::Classes::StdWndProc(HWND__*, unsigned int, unsigned long long, unsigned long long)
:00007FFE249ABC50 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AB94C ; C:\WINDOWS\System32\USER32.dll
:00007FFE249C11F3 ; C:\WINDOWS\System32\USER32.dll
:00007FFE274A90B4 ; <UNKNOWN>
:00007FFE23DF1164 ; C:\WINDOWS\System32\win32u.dll
:00007FFE249AB060 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AAEE8 ; C:\WINDOWS\System32\USER32.dll
:00007FFE16B46194 ; C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.0_none_108e4f62dfe5d999\COMCTL32.DLL
:00007FFE16B74CE6 ; C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.0_none_108e4f62dfe5d999\COMCTL32.DLL
:00007FFE249ABC50 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AB80B ; C:\WINDOWS\System32\USER32.dll
:0000000000ce12b7 ; Vcl::Controls::TWinControl::DefaultHandler(void*)
:0000000000cdb1dd ; Vcl::Controls::TControl::WMLButtonUp(Winapi::Messages::TWMMouse&)
:0000000000bbe745 ; System::TObject::Dispatch(void*)
:0000000000cda420 ; Vcl::Controls::TControl::WndProc(Winapi::Messages::TMessage&)
:0000000000ce1128 ; Vcl::Controls::TWinControl::WndProc(Winapi::Messages::TMessage&)
:0000000000cfbd75 ; Vcl::Stdctrls::TButtonControl::WndProc(Winapi::Messages::TMessage&)
:0000000000ce03ec ; Vcl::Controls::TWinControl::MainWndProc(Winapi::Messages::TMessage&)
:0000000000c62786 ; System::Classes::StdWndProc(HWND__*, unsigned int, unsigned long long, unsigned long long)
:00007FFE249ABC50 ; C:\WINDOWS\System32\USER32.dll
:00007FFE249AB5CF ; C:\WINDOWS\System32\USER32.dll
:0000000000dccf13 ; Vcl::Forms::TApplication::ProcessMessage(tagMSG&)
:0000000000dccf88 ; Vcl::Forms::TApplication::HandleMessage()
:0000000000dcd3d6 ; Vcl::Forms::TApplication::Run()
:0000000000441577 ; wWinMain
:0000000002332c38 ; _wstartup

Back to Thread List

Legend
	Helpful Answer (5 pts)
	Correct Answer (10 pts)

Developer Tools

Database Tools