On 08/05/2013 16:35, silvioprog wrote:
2013/5/8 silvioprog <[email protected] <mailto:[email protected]>>
2013/5/8 Martin <[email protected] <mailto:[email protected]>>
[...]
Sorry, no that was not fixed.
I was told something about path loading. That was hopped to
fix initial issue. Is that also still there?
Can you try the 2 debugln?
Because we still need to find out who is the right person to
look at this after all
Sorry about the mess.
No problem friend. :)
I'll do it now, a minute...
Done:
http://pastebin.com/HC7bcTay
Ok. dumb question on my site: did the assembler window show, or did it
work without it?
Because I cant see the asm stuff in the log.
Well looking for it, I can now see it way down. But a completely
different situation,
*stopped,reason="signal-received",signal-name="SIGPIPE",signal-meaning="Broken
pipe
That triggers different code...
So question: has the original issue been resolved ?
About the new one, I can see what happens.
The stopped position does not have debug info, so it can not display.
It should try to find a position on the stack....
That fails. And it fails because it is exclusively disabled at that time....
I am not sure of the exact reasons... But IIRC it would give
source-editor the hickups (crash it) if it was allowed.
I might find time to investigate that again, but I don't know.
Otherwise, this will need to wait. The original plan to resolve it
requires a big rewrite.
On your own risk:
debugger/gdbmidebugger line 5185
function TGDBMIDebuggerCommandExecute.ProcessStopped(const AParams: String;
.......
procedure ProcessSignalReceived(const AList: TGDBMINameValueList);
.......
FTheDebugger.QueueExecuteLock;
try
if not AIgnoreSigIntState
or not SigInt
then ProcessFrame(F);
finally
FTheDebugger.QueueExecuteUnlock;
end;
end;
remove the lock and unlock.
IIRC it is tricky to get the crash. So you might get a long way before
it happens
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
