[fpc-devel] -dTEST_WIN32_SEH

Martin Frb lazarus at mfriebe.de
Sun Apr 13 17:06:09 CEST 2014

On 13/04/2014 16:02, Martin Frb wrote:
> Sorry.
> But the below on hold.
> I just found the log at the issue. And it seems fpc_raise was called.
> My fault

OK, I excuse it by being Sunday afternoon. reread. Definitely  not called.

> On 13/04/2014 15:58, Martin Frb wrote:
>> On 13/04/2014 15:49, Sergei Gorelkin wrote:
>>>> If so, how can the debugger get notified (before the longjmp), in a 
>>>> way, that it can get the address
>>>> where the problem occurred?
>>>> with raise exception the debugger can set a breakpoint, because 
>>>> raise exception is defined [public
>>>> alias ...] so the debugger can read the address by knowing the name.
>>>> But the new code does not have that....
>>> The new fpc_raiseexception procedure has the same public alias as 
>>> before. Each of the handler routines mentioned above also has a 
>>> public alias.
>> I am looking at http://bugs.freepascal.org/view.php?id=26013#bugnotes
>> I still await feedback.
>> But it does look like it might be:
>> - An external dll has risen an exception
>> - The fpc_raiseexception was not called (as there is no mention that 
>> the IDE showed the debug dialog that is triggered by exceptions in 
>> the debugger)
>> - An except handle was reached (in the LCL / the application except 
>> handler, that does show the dialog for otherwise unhandled exceptions
>> Yes the debugger could propably gen "fpc_catches" or similar). But at 
>> that point. the instruction pointer and stack would be at the except. 
>> The position (in the dll) where the error occurred, would be lost.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

More information about the fpc-devel mailing list