|
Eric Dong(deleted)
|
Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/02/2009 12:03 PM
post23227
|
Debugger problem - Setting Dynamic-Linker Breakpoint
When i started debugging my program in tau IDE, it got blocked at pthread_mutex_unlock(), everytime i ran program at
full speed, it got blocked here and prompted the following error, appreciate your suggestions.
Setting Dynamic-Linker Breakpoint based on C:/QNX632/target/qnx6/x86/usr/lib/ldqnx.so.2
0xb0334792 in _start_ ()
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
Stopped due to shared library event
[Switching to process 98321 (state = 0x03)]
Thanks,
Eric
|
|
|
|
|
|
Elena Laskavaia
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Elena Laskavaia
03/02/2009 12:20 PM
post23230
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
There is no error in this log.
What do you mean "blocked"? If program stopps at mutext_lock means it
cannot acquire the lock,,
check if you have a deadlock.
Eric Dong wrote:
> When i started debugging my program in tau IDE, it got blocked at pthread_mutex_unlock(), everytime i ran program at
full speed, it got blocked here and prompted the following error, appreciate your suggestions.
>
> Setting Dynamic-Linker Breakpoint based on C:/QNX632/target/qnx6/x86/usr/lib/ldqnx.so.2
> 0xb0334792 in _start_ ()
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> [Switching to process 98321 (state = 0x03)]
>
> Thanks,
> Eric
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23227
>
>
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Aleksandar Ristovski(deleted)
03/02/2009 12:57 PM
post23237
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
The output suggests missing symbols from your ldqnx.so.2 on
the host. I am not sure why would that happen. Have you
changed ldqnx.so.2/libc.so.2 on your host?
What is the gdb version you are using?
Thanks,
Aleksandar
Eric Dong wrote:
> When i started debugging my program in tau IDE, it got blocked at pthread_mutex_unlock(), everytime i ran program at
full speed, it got blocked here and prompted the following error, appreciate your suggestions.
>
> Setting Dynamic-Linker Breakpoint based on C:/QNX632/target/qnx6/x86/usr/lib/ldqnx.so.2
> 0xb0334792 in _start_ ()
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> Stopped due to shared library event
> [Switching to process 98321 (state = 0x03)]
>
> Thanks,
> Eric
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23227
>
|
|
|
|
|
|
Eric Dong(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/03/2009 2:01 AM
post23297
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
thx, actually it should be a breakpoint, since i still could use 'step over' to go thru the codes. Though i didnot set a
breakpoint at the "pthread_mutex_lock()" code, it stopped every time when i resumed the program.
For the gdb version, i used the gdb-6.7-u10. I have rebuilt the image with the ldqnx.so.2 on my XP machine installed
with the IDE4.0.1. But still the problem.
Best,
Eric
|
|
|
|
|
|
Elena Laskavaia
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Elena Laskavaia
03/03/2009 9:12 AM
post23310
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
You have no breakpoints and it stops anyways? Can you type info breakpoints in the gdb console to see what gdb thinks
about breakpoints?
Eric Dong wrote:
> thx, actually it should be a breakpoint, since i still could use 'step over' to go thru the codes. Though i didnot set
a breakpoint at the "pthread_mutex_lock()" code, it stopped every time when i resumed the program.
>
> For the gdb version, i used the gdb-6.7-u10. I have rebuilt the image with the ldqnx.so.2 on my XP machine installed
with the IDE4.0.1. But still the problem.
>
>
> Best,
> Eric
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23297
>
|
|
|
|
|
|
Eric Dong(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/03/2009 9:32 AM
post23321
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Num Type Disp Enb Address What
1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *) at ....
breakpoint already hit 14 times
......
It showed that this breakpoint had already been hit 14 times, but this was the output when the program just got started.
Thanks,
Eric
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Aleksandar Ristovski(deleted)
03/03/2009 9:37 AM
post23323
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Odd.
Could you also do
maint info b
that will list "hidden" breakpoints (shlib events).
Eric Dong wrote:
> Num Type Disp Enb Address What
> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *) at ....
> breakpoint already hit 14 times
> ......
>
> It showed that this breakpoint had already been hit 14 times, but this was the output when the program just got
started.
>
> Thanks,
> Eric
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23321
>
|
|
|
|
|
|
Eric Dong(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/03/2009 9:47 AM
post23328
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
the console output:
-6 longjmp keep n 0xb032256c <longjmp>
-7 longjmp keep n 0xb0321d6e <_longjmp>
-8 longjmp keep n 0xb03177f0 <siglongjmp>
-9 longjmp resume keep n 0x00000000
-10 shlib events keep y 0xb033184c <_dl_debug_state>
breakpoint already hit 8 times
may have any clues from this?
> Odd.
>
> Could you also do
>
> maint info b
>
> that will list "hidden" breakpoints (shlib events).
>
> Eric Dong wrote:
> > Num Type Disp Enb Address What
> > 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
> > 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
> > 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *) at .
> ...
> > breakpoint already hit 14 times
> > ......
> >
> > It showed that this breakpoint had already been hit 14 times, but this was
> the output when the program just got started.
> >
> > Thanks,
> > Eric
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post23321
> >
>
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Aleksandar Ristovski(deleted)
03/03/2009 9:49 AM
post23330
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Eric Dong wrote:
> the console output:
> -6 longjmp keep n 0xb032256c <longjmp>
> -7 longjmp keep n 0xb0321d6e <_longjmp>
> -8 longjmp keep n 0xb03177f0 <siglongjmp>
> -9 longjmp resume keep n 0x00000000
> -10 shlib events keep y 0xb033184c <_dl_debug_state>
> breakpoint already hit 8 times
Oddly, this looks as it should. This is correct -
_dl_debug_state is where gdb places shlib events breakpoint.
The address is also correct. I will go through your session
log again.
>
> may have any clues from this?
>
>
>> Odd.
>>
>> Could you also do
>>
>> maint info b
>>
>> that will list "hidden" breakpoints (shlib events).
>>
>> Eric Dong wrote:
>>> Num Type Disp Enb Address What
>>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
>>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
>>> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *) at .
>> ...
>>> breakpoint already hit 14 times
>>> ......
>>>
>>> It showed that this breakpoint had already been hit 14 times, but this was
>> the output when the program just got started.
>>> Thanks,
>>> Eric
>>>
>>> _______________________________________________
>>> General
>>> http://community.qnx.com/sf/go/post23321
>>>
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23328
>
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Aleksandar Ristovski(deleted)
03/03/2009 9:52 AM
post23332
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
There isn't a session log. The messages "Stopped due to
shared library event" are o.k., as Elena said IDE silently
tells gdb to continue there.
Could you create a full gdb session log and attach it here?
|
|
|
|
|
|
Elena Laskavaia
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Elena Laskavaia
03/03/2009 9:54 AM
post23334
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
It is not easy to do with IDE 4.0.1. Full debug log is log of all commands between IDE and gdb. It is very easy to do
with IDE 4.5 (Option in Debug tab of launch config).
Can you install IDE 4.5 by any chance to try it?
Aleksandar Ristovski wrote:
> There isn't a session log. The messages "Stopped due to
> shared library event" are o.k., as Elena said IDE silently
> tells gdb to continue there.
>
> Could you create a full gdb session log and attach it here?
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23332
>
|
|
|
|
|
|
Elena Laskavaia
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Elena Laskavaia
03/03/2009 9:49 AM
post23329
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
IDE enables breakpoints on shlib events by default, but it resumes the inferior after processing it.
It only stops for each shared library load, it would not stop (internally) every time mutex function is called.
Aleksandar Ristovski wrote:
> Odd.
>
> Could you also do
>
> maint info b
>
> that will list "hidden" breakpoints (shlib events).
>
> Eric Dong wrote:
>> Num Type Disp Enb Address What
>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
>> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *) at ....
>> breakpoint already hit 14 times
>> ......
>>
>> It showed that this breakpoint had already been hit 14 times, but this was the output when the program just got
started.
>>
>> Thanks,
>> Eric
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post23321
>>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23323
>
|
|
|
|
|
|
Eric Dong(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/03/2009 10:03 AM
post23337
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
thanks, i have just commented the mutex codes, and still stopped at the function, just at the next statement. But when i
commented this function, the debugger worked properly. So what in this function may cause the debugger to set
breakpoints automatically?
Thanks,
Eric
> IDE enables breakpoints on shlib events by default, but it resumes the
> inferior after processing it.
> It only stops for each shared library load, it would not stop (internally)
> every time mutex function is called.
>
> Aleksandar Ristovski wrote:
> > Odd.
> >
> > Could you also do
> >
> > maint info b
> >
> > that will list "hidden" breakpoints (shlib events).
> >
> > Eric Dong wrote:
> >> Num Type Disp Enb Address What
> >> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
> >> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
> >> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *) at
> ....
> >> breakpoint already hit 14 times
> >> ......
> >>
> >> It showed that this breakpoint had already been hit 14 times, but this was
> the output when the program just got started.
> >>
> >> Thanks,
> >> Eric
> >>
> >> _______________________________________________
> >> General
> >> http://community.qnx.com/sf/go/post23321
> >>
> >
> >
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post23323
> >
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Aleksandar Ristovski(deleted)
03/03/2009 10:04 AM
post23338
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Eric, could you try using gdb from command line?
That way we could diagnose this much faster.
Thanks,
Aleksandar
Eric Dong wrote:
> thanks, i have just commented the mutex codes, and still stopped at the function, just at the next statement. But when
i commented this function, the debugger worked properly. So what in this function may cause the debugger to set
breakpoints automatically?
>
> Thanks,
> Eric
>
>
>> IDE enables breakpoints on shlib events by default, but it resumes the
>> inferior after processing it.
>> It only stops for each shared library load, it would not stop (internally)
>> every time mutex function is called.
>>
>> Aleksandar Ristovski wrote:
>>> Odd.
>>>
>>> Could you also do
>>>
>>> maint info b
>>>
>>> that will list "hidden" breakpoints (shlib events).
>>>
>>> Eric Dong wrote:
>>>> Num Type Disp Enb Address What
>>>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
>>>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
>>>> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *) at
>> ....
>>>> breakpoint already hit 14 times
>>>> ......
>>>>
>>>> It showed that this breakpoint had already been hit 14 times, but this was
>> the output when the program just got started.
>>>> Thanks,
>>>> Eric
>>>>
>>>> _______________________________________________
>>>> General
>>>> http://community.qnx.com/sf/go/post23321
>>>>
>>>
>>>
>>> _______________________________________________
>>> General
>>> http://community.qnx.com/sf/go/post23323
>>>
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23337
>
|
|
|
|
|
|
Eric Dong(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/03/2009 10:21 AM
post23341
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
thanks, i tried the command line gdb, with ''c" to run the program at full speed, also stops at the same line.
Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/../a.cpp:358
358 pthread_mutex_unlock(&m_mtxCmd);
As i just posted, only when i totally commented the GetCommand method, the program will run as expected.
Eric
> Eric, could you try using gdb from command line?
>
> That way we could diagnose this much faster.
>
> Thanks,
>
> Aleksandar
>
>
> Eric Dong wrote:
> > thanks, i have just commented the mutex codes, and still stopped at the
> function, just at the next statement. But when i commented this function, the
> debugger worked properly. So what in this function may cause the debugger to
> set breakpoints automatically?
> >
> > Thanks,
> > Eric
> >
> >
> >> IDE enables breakpoints on shlib events by default, but it resumes the
> >> inferior after processing it.
> >> It only stops for each shared library load, it would not stop (internally)
>
> >> every time mutex function is called.
> >>
> >> Aleksandar Ristovski wrote:
> >>> Odd.
> >>>
> >>> Could you also do
> >>>
> >>> maint info b
> >>>
> >>> that will list "hidden" breakpoints (shlib events).
> >>>
> >>> Eric Dong wrote:
> >>>> Num Type Disp Enb Address What
> >>>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
> >>>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
> >>>> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *)
> at
> >> ....
> >>>> breakpoint already hit 14 times
> >>>> ......
> >>>>
> >>>> It showed that this breakpoint had already been hit 14 times, but this
> was
> >> the output when the program just got started.
> >>>> Thanks,
> >>>> Eric
> >>>>
> >>>> _______________________________________________
> >>>> General
> >>>> http://community.qnx.com/sf/go/post23321
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> General
> >>> http://community.qnx.com/sf/go/post23323
> >>>
> >
> >
> >
> >
> > _______________________________________________
> > General
> > http://community.qnx.com/sf/go/post23337
> >
>
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Aleksandar Ristovski(deleted)
03/03/2009 10:24 AM
post23342
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Ok, now we can do a full log which would help me get an idea
of what is going on. With your original test (which doesn't
work), do the following:
When you start gdb from command line, something like:
C:\>ntox86-gdb <your binary> --ex "target qnx
<targethost>:8000" --ex "up <your binaryonhost> /tmp/test"
(gdb) set logging file c:\gdb.log
(gdb) set logging on
(gdb) set debug infrun 1
(gdb) start
....
(gdb) c
...
...
(gdb) q
And then attach your gdb.log here.
Thanks,
Aleksandar
Eric Dong wrote:
> thanks, i tried the command line gdb, with ''c" to run the program at full speed, also stops at the same line.
> Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/../a.cpp:358
> 358 pthread_mutex_unlock(&m_mtxCmd);
>
> As i just posted, only when i totally commented the GetCommand method, the program will run as expected.
>
> Eric
>
|
|
|
|
|
|
Elena Laskavaia
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Elena Laskavaia
03/03/2009 10:29 AM
post23344
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
But from your info breakpoints command it is clear that gdb has breakpoint set on this function. Do you have .gdbinit
file that sets them?
Eric Dong wrote:
> thanks, i tried the command line gdb, with ''c" to run the program at full speed, also stops at the same line.
> Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/../a.cpp:358
> 358 pthread_mutex_unlock(&m_mtxCmd);
>
> As i just posted, only when i totally commented the GetCommand method, the program will run as expected.
>
> Eric
>
>> Eric, could you try using gdb from command line?
>>
>> That way we could diagnose this much faster.
>>
>> Thanks,
>>
>> Aleksandar
>>
>>
>> Eric Dong wrote:
>>> thanks, i have just commented the mutex codes, and still stopped at the
>> function, just at the next statement. But when i commented this function, the
>> debugger worked properly. So what in this function may cause the debugger to
>> set breakpoints automatically?
>>> Thanks,
>>> Eric
>>>
>>>
>>>> IDE enables breakpoints on shlib events by default, but it resumes the
>>>> inferior after processing it.
>>>> It only stops for each shared library load, it would not stop (internally)
>>>> every time mutex function is called.
>>>>
>>>> Aleksandar Ristovski wrote:
>>>>> Odd.
>>>>>
>>>>> Could you also do
>>>>>
>>>>> maint info b
>>>>>
>>>>> that will list "hidden" breakpoints (shlib events).
>>>>>
>>>>> Eric Dong wrote:
>>>>>> Num Type Disp Enb Address What
>>>>>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
>>>>>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
>>>>>> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *)
>> at
>>>> ....
>>>>>> breakpoint already hit 14 times
>>>>>> ......
>>>>>>
>>>>>> It showed that this breakpoint had already been hit 14 times, but this
>> was
>>>> the output when the program just got started.
>>>>>> Thanks,
>>>>>> Eric
>>>>>>
>>>>>> _______________________________________________
>>>>>> General
>>>>>> http://community.qnx.com/sf/go/post23321
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> General
>>>>> http://community.qnx.com/sf/go/post23323
>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> General
>>> http://community.qnx.com/sf/go/post23337
>>>
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post23341
>
|
|
|
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Aleksandar Ristovski(deleted)
03/03/2009 10:37 AM
post23346
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
I assumed he wanted it to be there.
But if the question is really why gdb breaks there, then
Elena has a very good point: you might have a .gdbinit file
that sets those breakpoints. I somehow assumed gdb stops
somewhere inside the function where a breakpoint does not exist.
To test this, start gdb from command line using --nx option:
C:\>ntox86-gdb --nx ....
which will instruct gdb to not read init files.
Elena Laskavaia wrote:
> But from your info breakpoints command it is clear that gdb has breakpoint set on this function. Do you have .gdbinit
file that sets them?
>
> Eric Dong wrote:
>> thanks, i tried the command line gdb, with ''c" to run the program at full speed, also stops at the same line.
>> Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/../a.cpp:358
>> 358 pthread_mutex_unlock(&m_mtxCmd);
>>
>> As i just posted, only when i totally commented the GetCommand method, the program will run as expected.
>>
>> Eric
>>
>>> Eric, could you try using gdb from command line?
>>>
>>> That way we could diagnose this much faster.
>>>
>>> Thanks,
>>>
>>> Aleksandar
>>>
>>>
>>> Eric Dong wrote:
>>>> thanks, i have just commented the mutex codes, and still stopped at the
>>> function, just at the next statement. But when i commented this function, the
>>> debugger worked properly. So what in this function may cause the debugger to
>>> set breakpoints automatically?
>>>> Thanks,
>>>> Eric
>>>>
>>>>
>>>>> IDE enables breakpoints on shlib events by default, but it resumes the
>>>>> inferior after processing it.
>>>>> It only stops for each shared library load, it would not stop (internally)
>>>>> every time mutex function is called.
>>>>>
>>>>> Aleksandar Ristovski wrote:
>>>>>> Odd.
>>>>>>
>>>>>> Could you also do
>>>>>>
>>>>>> maint info b
>>>>>>
>>>>>> that will list "hidden" breakpoints (shlib events).
>>>>>>
>>>>>> Eric Dong wrote:
>>>>>>> Num Type Disp Enb Address What
>>>>>>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
>>>>>>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
>>>>>>> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *)
>>> at
>>>>> ....
>>>>>>> breakpoint already hit 14 times
>>>>>>> ......
>>>>>>>
>>>>>>> It showed that this breakpoint had already been hit 14 times, but this
>>> was
>>>>> the output when the program just got started.
>>>>>>> Thanks,
>>>>>>> Eric
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> General
>>>>>>> http://community.qnx.com/sf/go/post23321
>>>>>>>
>>>>>> _______________________________________________
>>>>>> General
>>>>>> http://community.qnx.com/sf/go/post23323
>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> General
>>>> http://community.qnx.com/sf/go/post23337
>>>>
>>
>>
>>
>>...
|
|
|
|
|
|
Elena Laskavaia
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Elena Laskavaia
03/03/2009 10:39 AM
post23349
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
It stops on breakpoint 3 and it is breakpoint from the list. I assume user did not want it there and does not know how
it was set. Is it correct?
Aleksandar Ristovski wrote:
> I assumed he wanted it to be there.
>
> But if the question is really why gdb breaks there, then
> Elena has a very good point: you might have a .gdbinit file
> that sets those breakpoints. I somehow assumed gdb stops
> somewhere inside the function where a breakpoint does not exist.
>
> To test this, start gdb from command line using --nx option:
>
> C:\>ntox86-gdb --nx ....
>
> which will instruct gdb to not read init files.
>
> Elena Laskavaia wrote:
>> But from your info breakpoints command it is clear that gdb has breakpoint set on this function. Do you have .gdbinit
file that sets them?
>>
>> Eric Dong wrote:
>>> thanks, i tried the command line gdb, with ''c" to run the program at full speed, also stops at the same line.
>>> Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/../a.cpp:358
>>> 358 pthread_mutex_unlock(&m_mtxCmd);
>>>
>>> As i just posted, only when i totally commented the GetCommand method, the program will run as expected.
>>>
>>> Eric
>>>
>>>> Eric, could you try using gdb from command line?
>>>>
>>>> That way we could diagnose this much faster.
>>>>
>>>> Thanks,
>>>>
>>>> Aleksandar
>>>>
>>>>
>>>> Eric Dong wrote:
>>>>> thanks, i have just commented the mutex codes, and still stopped at the
>>>> function, just at the next statement. But when i commented this function, the
>>>> debugger worked properly. So what in this function may cause the debugger to
>>>> set breakpoints automatically?
>>>>> Thanks,
>>>>> Eric
>>>>>
>>>>>
>>>>>> IDE enables breakpoints on shlib events by default, but it resumes the
>>>>>> inferior after processing it.
>>>>>> It only stops for each shared library load, it would not stop (internally)
>>>>>> every time mutex function is called.
>>>>>>
>>>>>> Aleksandar Ristovski wrote:
>>>>>>> Odd.
>>>>>>>
>>>>>>> Could you also do
>>>>>>>
>>>>>>> maint info b
>>>>>>>
>>>>>>> that will list "hidden" breakpoints (shlib events).
>>>>>>>
>>>>>>> Eric Dong wrote:
>>>>>>>> Num Type Disp Enb Address What
>>>>>>>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
>>>>>>>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
>>>>>>>> 3 breakpoint keep y 0x0805fd8c in clsCTL::GetCommand(COMMAND *)
>>>> at
>>>>>> ....
>>>>>>>> breakpoint already hit 14 times
>>>>>>>> ......
>>>>>>>>
>>>>>>>> It showed that this breakpoint had already been hit 14 times, but this
>>>> was
>>>>>> the output when the program just got started.
>>>>>>>> Thanks,
>>>>>>>> Eric
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> General
>>>>>>>>...
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Colin Burgess(deleted)
03/03/2009 10:42 AM
post23351
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Perhaps he is being confused because he set the breakpoint on the
function, but gdb placed the breakpoint on the first executable
line in the function, which called pthread_mutex_lock?
Elena Laskavaia wrote:
> It stops on breakpoint 3 and it is breakpoint from the list. I assume user did not want it there and does not know how
it was set. Is it correct?
>
> Aleksandar Ristovski wrote:
>
>> I assumed he wanted it to be there.
>>
>> But if the question is really why gdb breaks there, then
>> Elena has a very good point: you might have a .gdbinit file
>> that sets those breakpoints. I somehow assumed gdb stops
>> somewhere inside the function where a breakpoint does not exist.
>>
>> To test this, start gdb from command line using --nx option:
>>
>> C:\>ntox86-gdb --nx ....
>>
>> which will instruct gdb to not read init files.
>>
>> Elena Laskavaia wrote:
>>
>>> But from your info breakpoints command it is clear that gdb has breakpoint set on this function. Do you have .
gdbinit file that sets them?
>>>
>>> Eric Dong wrote:
>>>
>>>> thanks, i tried the command line gdb, with ''c" to run the program at full speed, also stops at the same line.
>>>> Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/../a.cpp:358
>>>> 358 pthread_mutex_unlock(&m_mtxCmd);
>>>>
>>>> As i just posted, only when i totally commented the GetCommand method, the program will run as expected.
>>>>
>>>> Eric
>>>>
>>>>
>>>>> Eric, could you try using gdb from command line?
>>>>>
>>>>> That way we could diagnose this much faster.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Aleksandar
>>>>>
>>>>>
>>>>> Eric Dong wrote:
>>>>>
>>>>>> thanks, i have just commented the mutex codes, and still stopped at the
>>>>>>
>>>>> function, just at the next statement. But when i commented this function, the
>>>>> debugger worked properly. So what in this function may cause the debugger to
>>>>> set breakpoints automatically?
>>>>>
>>>>>> Thanks,
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>>
>>>>>>> IDE enables breakpoints on shlib events by default, but it resumes the
>>>>>>> inferior after processing it.
>>>>>>> It only stops for each shared library load, it would not stop (internally)
>>>>>>> every time mutex function is called.
>>>>>>>
>>>>>>> Aleksandar Ristovski wrote:
>>>>>>>
>>>>>>>> Odd.
>>>>>>>>
>>>>>>>> Could you also do
>>>>>>>>
>>>>>>>> maint info b
>>>>>>>>
>>>>>>>> that will list "hidden" breakpoints (shlib events).
>>>>>>>>
>>>>>>>> Eric Dong wrote:
>>>>>>>>
>>>>>>>>> Num Type Disp Enb Address What
>>>>>>>>> 1 breakpoint keep n 0x080635c9 in clsCTL::A5(void) at ....
>>>>>>>>> 2 breakpoint keep y 0x0806411a in clsCTL::A7(void) at .....
>>>>>>>>> 3 breakpoint keep y ...
View Full Message
|
|
|
|
|
|
Eric Dong(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/03/2009 12:52 PM
post23370
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Thanks for all your replies.
The fact is: i didnot set a breakpoint on the line where it stopped, perhaps it is caused by the .gdbinit file as you
guys suggested. I will try the method of not using the .gdbinit and update it tmr. thx.
Eric
> Perhaps he is being confused because he set the breakpoint on the
> function, but gdb placed the breakpoint on the first executable
> line in the function, which called pthread_mutex_lock?
>
> Elena Laskavaia wrote:
> > It stops on breakpoint 3 and it is breakpoint from the list. I assume user
> did not want it there and does not know how it was set. Is it correct?
> >
> > Aleksandar Ristovski wrote:
> >
> >> I assumed he wanted it to be there.
> >>
> >> But if the question is really why gdb breaks there, then
> >> Elena has a very good point: you might have a .gdbinit file
> >> that sets those breakpoints. I somehow assumed gdb stops
> >> somewhere inside the function where a breakpoint does not exist.
> >>
> >> To test this, start gdb from command line using --nx option:
> >>
> >> C:\>ntox86-gdb --nx ....
> >>
> >> which will instruct gdb to not read init files.
> >>
> >> Elena Laskavaia wrote:
> >>
> >>> But from your info breakpoints command it is clear that gdb has breakpoint
> set on this function. Do you have .gdbinit file that sets them?
> >>>
> >>> Eric Dong wrote:
> >>>
> >>>> thanks, i tried the command line gdb, with ''c" to run the program at
> full speed, also stops at the same line.
> >>>> Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/.
> ./a.cpp:358
> >>>> 358 pthread_mutex_unlock(&m_mtxCmd);
> >>>>
> >>>> As i just posted, only when i totally commented the GetCommand method,
> the program will run as expected.
> >>>>
> >>>> Eric
> >>>>
> >>>>
> >>>>> Eric, could you try using gdb from command line?
> >>>>>
> >>>>> That way we could diagnose this much faster.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Aleksandar
> >>>>>
> >>>>>
> >>>>> Eric Dong wrote:
> >>>>>
> >>>>>> thanks, i have just commented the mutex codes, and still stopped at the
>
> >>>>>>
> >>>>> function, just at the next statement. But when i commented this function
> , the
> >>>>> debugger worked properly. So what in this function may cause the
> debugger to
> >>>>> set breakpoints automatically?
> >>>>>
> >>>>>> Thanks,
> >>>>>> Eric
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> IDE enables breakpoints on shlib events by default, but it resumes the
>
> >>>>>>> inferior after processing it.
> >>>>>>> It only stops for each shared library load, it would not stop (
> internally)
> >>>>>>> every time mutex function is called.
> >>>>>>>
> >>>>>>> Aleksandar Ristovski wrote:
> >>>>>>>
> >>>>>>>> Odd.
> >>>>>>>>
> >>>>>>>> Could you also do
>...
View Full Message
|
|
|
|
|
|
Colin Burgess(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Colin Burgess(deleted)
03/03/2009 12:58 PM
post23373
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Be aware that gdb may sometimes elect to place a breakpoint at a subtly
different location than you expect.
When you ask it to set a breakpoint at a function/method, it will place
the breakpoint on the first line of executable
code PAST THE PROLOGUE.
This may be compounded by C++, I'm not 100% sure on that one.
Certainly based on the output of your gdb log, as far as gdb is
concerned the breakpoint is there, at line 358, exactly
where it stopped.
So if there is an issue, it is with where gdb is choosing to place the
breakpoint.
Regards,
Colin
Eric Dong wrote:
> Thanks for all your replies.
> The fact is: i didnot set a breakpoint on the line where it stopped, perhaps it is caused by the .gdbinit file as you
guys suggested. I will try the method of not using the .gdbinit and update it tmr. thx.
>
> Eric
>
>
>> Perhaps he is being confused because he set the breakpoint on the
>> function, but gdb placed the breakpoint on the first executable
>> line in the function, which called pthread_mutex_lock?
>>
>> Elena Laskavaia wrote:
>>
>>> It stops on breakpoint 3 and it is breakpoint from the list. I assume user
>>>
>> did not want it there and does not know how it was set. Is it correct?
>>
>>> Aleksandar Ristovski wrote:
>>>
>>>
>>>> I assumed he wanted it to be there.
>>>>
>>>> But if the question is really why gdb breaks there, then
>>>> Elena has a very good point: you might have a .gdbinit file
>>>> that sets those breakpoints. I somehow assumed gdb stops
>>>> somewhere inside the function where a breakpoint does not exist.
>>>>
>>>> To test this, start gdb from command line using --nx option:
>>>>
>>>> C:\>ntox86-gdb --nx ....
>>>>
>>>> which will instruct gdb to not read init files.
>>>>
>>>> Elena Laskavaia wrote:
>>>>
>>>>
>>>>> But from your info breakpoints command it is clear that gdb has breakpoint
>>>>>
>> set on this function. Do you have .gdbinit file that sets them?
>>
>>>>> Eric Dong wrote:
>>>>>
>>>>>
>>>>>> thanks, i tried the command line gdb, with ''c" to run the program at
>>>>>>
>> full speed, also stops at the same line.
>>
>>>>>> Breakpoint 3, clsCTL::GetCommand (this=0x80c4ce5, pCmd=0x7f21df8) at D:/.
>>>>>>
>> ./a.cpp:358
>>
>>>>>> 358 pthread_mutex_unlock(&m_mtxCmd);
>>>>>>
>>>>>> As i just posted, only when i totally commented the GetCommand method,
>>>>>>
>> the program will run as expected.
>>
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Eric, could you try using gdb from command line?
>>>>>>>
>>>>>>> That way we could diagnose this much faster.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Aleksandar
>>>>>>>
>>>>>>>
>>>>>>> Eric Dong wrote:
>>>>>>>
>>>>>>>
>>>>>>>> thanks, i have just commented the mutex codes, and still stopped at the
>>>>>>>>
>>
>> ...
View Full Message
|
|
|
|
|
|
Eric Dong(deleted)
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
|
|
Eric Dong(deleted)
03/04/2009 8:36 AM
post23452
|
Re: Debugger problem - Setting Dynamic-Linker Breakpoint
Hi all,
I have solved the problem. I just cleared all the breakpoints in all my projects. Then the gdb worked fine. Probably
some early defined breakpoints left, but located at the wrong line, which led to the problem. Thank you all.
Eric
|
|
|
|
|
|
