| stop-on-solib-events [message #213925] |
Mon, 14 April 2008 12:02  |
Eclipse User |
|
|
|
Originally posted by: nick.spacek.gmail.com
Hi there,
I'm using Eclipse 3.3.2 on Windows XP with CDT 4.0.3.200802251018.
So with that out of the way, the problem I'm having is that when
attempting to Debug, it breaks about 10 times before actually starting the
program at this call: ntdll!ldrAccessResource().
I looked through the gdb console and found this command:
set stop-on-solib-events 1
In the Debug options, I confirmed that the checkbox "Stop on shared
library events" is NOT checked. I tried checking it. The command
remained. I went back in and unchecked it. Now the console shows:
set stop-on-solib-events 0
...followed by
set stop-on-solib-events 1
I'm not sure where this command is coming from. I can't seem to get it to
stop. After the first ntdll break, I manually turn this option off from
the gdb console, and (no surprise here) execution reaches the program with
no further interruptions.
Does anyone have any ideas?
Thanks,
Nick Spacek
|
|
|
| Re: stop-on-solib-events [message #214509 is a reply to message #213925] |
Sun, 20 April 2008 09:06  |
| Eclipse User |
|
|
|
Originally posted by: ragatol.netsite.com.br
Nick Spacek escreveu:
> Hi there,
>
> I'm using Eclipse 3.3.2 on Windows XP with CDT 4.0.3.200802251018.
>
> So with that out of the way, the problem I'm having is that when
> attempting to Debug, it breaks about 10 times before actually starting
> the program at this call: ntdll!ldrAccessResource().
>
> I looked through the gdb console and found this command:
> set stop-on-solib-events 1
>
> In the Debug options, I confirmed that the checkbox "Stop on shared
> library events" is NOT checked. I tried checking it. The command
> remained. I went back in and unchecked it. Now the console shows:
>
> set stop-on-solib-events 0
>
> ..followed by
>
> set stop-on-solib-events 1
>
> I'm not sure where this command is coming from. I can't seem to get it
> to stop. After the first ntdll break, I manually turn this option off
> from the gdb console, and (no surprise here) execution reaches the
> program with no further interruptions.
>
> Does anyone have any ideas?
>
> Thanks,
> Nick Spacek
>
Hi Nick,
That's what Doug said to me at the MinGW-users list:
> Yes, this is something I've been trying to figure out too. I'm convinced
> at the moment that it's because of the way the CDT handles "pending"
> breakpoints, i.e. it tried to manage it itself. We set up
> stop-on-solib-events so that when DLLs get loaded, we try to set any of
> the breakpoints that failed during the main program load. I think gdb is
> choking on the solib event handling and you are showing a familiar stack
> trace that tells me you've run into the same thing.
>
> I'll be working on integrating the 6.8 gdb over the next few months and
> adding in proper support for gdb's pending breakpoints. In the meantime,
> things are kinda broken.
>
> Cheers,
> Doug Schaefer
>
>
In the meanwhile, you can use:
[Run] -> [Open Debug Dialog] -> [Debugger] -> [Shared Libraries] ->
deactivate check button [Load Shared Library Symbols automatically]
or use version 6.6 of gdb (6.7 does have the same problem).
best
Rafael Fernandes
|
|
|
| Re: stop-on-solib-events [message #227073 is a reply to message #214509] |
Thu, 20 November 2008 03:22 |
| Eclipse User |
|
|
|
Hi,
I am using CDT 5.0.1 release and gdb 6.8, and need to debug a dll.
My config is (in config->debugger->shared lib tabs):
-Enable: Load shared libraries symbols automatically
-Disable: Stop on shared library events
I found also that gdb stops many times as written previously.
Now after the 1st stops I just added the gdb cmd:
"set stop-on-solib-events 0"
Then after a run cmd, I don't have any more the
"ntdll!LdrAccessResource()" stops, but my dll breakpoint is never stopping
the run.
=> So I think the " set stop-on-solib-events 1" is correctly setup.
For me the solution is that CDT should recognize "solib-events" and if not
requested to
"Stop on shared library events", continue the execution.
CDT has to be able to sort events from my dll or not (thanks to the
breakpoint info)
I can't use the 6.6 workaround.
My application is debugging a PYD, python DLL.
The launch application is the python.exe interpreter using a .py script
files.
So I can't stop the execution with a breakpoint.
I think a
asm{int $3}
in my dll/pyd is a solution,
but I would appreciate a better solution.
Did you solved this issue ?
Thanks for your help !
Cheers,
Nicolas.
|
|
|
Powered by
FUDForum. Page generated in 0.17405 seconds
Home