[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