Christopher Hitchcock
|
Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/20/2009 2:16 PM
post24919
|
Unresolved Breakpoint warning in IDE 4.5 Tau
After upgrading to the 6.4 release with the Tau upgrade, I am unable to set a breakpoint when debugging via QConn (via
TCP/IP).
If I set a breakpoint while the code is running, or if the execution runs across a previously set breakpoint, the
program stops running and an error message stating "warning: Thread 1 has terminated." is logged to the GDB console. No
other errors are shown, even when using the verbose GDB logging.
Is there something I'm missing here?
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/20/2009 2:18 PM
post24920
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Could you post your verbose log?
Thanks,
Aleksandar
Christopher Hitchcock wrote:
> After upgrading to the 6.4 release with the Tau upgrade, I am unable to set a breakpoint when debugging via QConn (via
TCP/IP).
>
> If I set a breakpoint while the code is running, or if the execution runs across a previously set breakpoint, the
program stops running and an error message stating "warning: Thread 1 has terminated." is logged to the GDB console. No
other errors are shown, even when using the verbose GDB logging.
>
> Is there something I'm missing here?
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24919
>
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/23/2009 8:58 AM
post24988
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Here is my verbose GDB log. I had looked through this before but I didn't see anything that looked odd.
This log shows from the point the code started to the point where the breakpoint I had set has been hit.
I rolled back to pre-Tau 6.4.0 and the same problem is occurring. I've also tried different targets all with the same
result.
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/23/2009 9:20 AM
post24993
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Hello Christopher,
I don't think the log shows hitting your breakpoint, from
the log I see it hit temporary breakpoint in main.
I am not clear what is happening after the "thread 1 has
terminated" message, the program dies?
Is your breakpoint 1 set in a shared object (breakpoint in
sms_debug.c:1691)?
Thanks,
Aleksandar
Christopher Hitchcock wrote:
> Here is my verbose GDB log. I had looked through this before but I didn't see anything that looked odd.
>
> This log shows from the point the code started to the point where the breakpoint I had set has been hit.
>
> I rolled back to pre-Tau 6.4.0 and the same problem is occurring. I've also tried different targets all with the same
result.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24988
>
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/23/2009 9:29 AM
post24997
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
It always hits the temp breakpoint at main() correctly without an issue
I get that "thread 1 has terminated" message when the code execution hits the function that contains breakpoint 1. I
then have to kill my debugging session and do a hard reset of my target.
Breakpoint 1 is contained in a static library that my application uses.
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/23/2009 9:53 AM
post25002
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Ok, to analyze this I need your help.
Could you do this on your target:
open telnet or shell and then
# uname -a
(post output in your reply)
# PDEBUG_DEBUG=1 pdebug -v 8010 > /tmp/pdbgsession.log 2>&1
Since your target appears to die, please make sure path to
log is somewhere in a persistent storage.
At the same time, it would be useful if you could repeat
your debugging session from command line, that way we can
capture more gdb logging.
From command line, start your gdb:
c:\(your project directory)> ntoarm-gdb <your binary>
(gdb) set logging file c:\gdbsession.log
(gdb) set logging on
(gdb) target qnx 10.16.34.84:8010
...
(gdb) set debug infrun 1
...
(gdb) break sms_debug.c:1691
...
(gdb) start
...
(gdb) continue
Please attach both gdbsession.log and pdbgsession.log to
your reply.
Thank you,
Aleksandar
Christopher Hitchcock wrote:
> It always hits the temp breakpoint at main() correctly without an issue
>
> I get that "thread 1 has terminated" message when the code execution hits the function that contains breakpoint 1. I
then have to kill my debugging session and do a hard reset of my target.
>
> Breakpoint 1 is contained in a static library that my application uses.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post24997
>
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/23/2009 3:38 PM
post25045
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
I was able to do the steps listed, but I never seemed to hit the breakpoint I set.
Also, my stdout didn't show up in gdb, I thought it was supposed to?
In gdbsession.log, at line 80, gdb just sat there at the "wait_for_inferior" statement. I ended up hitting ctrl-c to
break it and quit gdb. This happened every time. Am I doing something wrong?
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/23/2009 3:52 PM
post25046
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
As for the gdb log, it looks like all works as expected, it
looks like your program is blocked in MsgSend which is
probably ok.
We need to reproduce conditions you are seeing in the IDE.
What were exact commands you were using in IDE? Could you
try to repeat exact steps in IDE that lead to the crash,
then using CLI equivalents repeat in CLI session, capturing
both logs. Here are command "translations":
IDE CLI(gdb command line interface):
setting breakpoint break <location>
run(F5) start
step into step
step over next
stop kill
That should be enough, I think.
pdbgsession.log you provided is not good; you need to kill
running pdebug instance before re-running the test.
Thanks,
Aleksandar
Christopher Hitchcock wrote:
> I was able to do the steps listed, but I never seemed to hit the breakpoint I set.
>
> Also, my stdout didn't show up in gdb, I thought it was supposed to?
>
> In gdbsession.log, at line 80, gdb just sat there at the "wait_for_inferior" statement. I ended up hitting ctrl-c to
break it and quit gdb. This happened every time. Am I doing something wrong?
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25045
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/23/2009 4:07 PM
post25047
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
When I launch the program remotely via GDB like this, where is stdout/stdin going?
I can't really reproduce it since I don't know where the stdout/stdin for my program is when I execute it in this
fashion. As the code is now, I need to key in some commands (done via the console in the IDE) to get it to the spot it
fails at.
Here is my uname -a results (forgot to post this earlier):
QNX localhost 6.4.0 2008/10/21-10:59:20EDT Texas_Instruments_DM355_EVM armle
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/23/2009 4:12 PM
post25048
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
stdout should be there; however, stdin will not.
What you can do is on your target, first start your program
(from shell/telnet):
# on -h <your binary>
Then, from your host, run gdb something like:
C:\>ntoarm-gdb <yourbinaryonthehost> --ex "target qnx <IP>:8010"
To find out what PID is your process, either open another
telnet session/shell and do a pidin or ps or from gdb:
(gdb) info pidlist
...
(gdb) attach <pid>
...
(gdb) break <your sourcefile>:<linenumber>
...
(gdb) tbreak main
...
(gdb) continue
and from there, repeat exact steps as in the IDE, using the
first shell/telnet where you typed "on ..." as your
program's stdin/out.
Christopher Hitchcock wrote:
> When I launch the program remotely via GDB like this, where is stdout/stdin going?
>
> I can't really reproduce it since I don't know where the stdout/stdin for my program is when I execute it in this
fashion. As the code is now, I need to key in some commands (done via the console in the IDE) to get it to the spot it
fails at.
>
> Here is my uname -a results (forgot to post this earlier):
> QNX localhost 6.4.0 2008/10/21-10:59:20EDT Texas_Instruments_DM355_EVM armle
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25047
>
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/23/2009 4:35 PM
post25051
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Ok, using on -h worked. Thanks.
I've attached the new logs.
Here are the steps I use:
1. Set the breakpoint (the breakpoint ends up being in a separate thread)
2. Start the application
3. Key in some commands to get to the chunk of code the breakpoint is set in (creates some threads and goes to a command
handler)
4. Watch the crash ("warning: Thread 1 has terminated")
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/24/2009 11:08 AM
post25113
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Hello Christopher,
I see nothing wrong in the logs.
From pdbgsession.log, I can see that it does hit your
breakpoint (at 0x109b48, which corresponds to
sms_debug.c:1691). I don't see anything odd with the logs,
except, of course, that I see the process is gone; and it
seems it is gone after gdb successfully received
notification from pdebug, and even asked for a list of
threads and received the reply. When it next tries to select
thread 1, the process appears to be gone.
This is quite confusing. Could you add some instrumentation
in your code, just before and after the breakpoint; then run
your program without the breakpoint and with it (just so we
see that it continues and "works" if the breakpoint is not
hit and dies when it is hit).
In addition, when recreating the logs, could you add this
command to gdb, just after "set debug infrun 1"
(gdb) set debug nto-debug 1
and then post the logs again, maybe this would give us some
clue to what is going on.
I would also need:
(gdb) show version
and
# uname -a
Finally, is there a possibility that your main thread really
exits (e.g. due to a watchdog timeout or something like that)?
Thank you,
Aleksandar
Christopher Hitchcock wrote:
> Ok, using on -h worked. Thanks.
>
> I've attached the new logs.
>
> Here are the steps I use:
> 1. Set the breakpoint (the breakpoint ends up being in a separate thread)
> 2. Start the application
> 3. Key in some commands to get to the chunk of code the breakpoint is set in (creates some threads and goes to a
command handler)
> 4. Watch the crash ("warning: Thread 1 has terminated")
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25051
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/24/2009 3:16 PM
post25131
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
New set of logs attached.
The groups of logs are:
--No breakpoint set
--Breakpoint set
--Reattaching to the process after you get the "Thread 1" error (see below)
I verified that if the breakpoint was not set then the code functions normally.
One interesting thing I found was that if I reattach to the process (since I started it on the host using "on -h") using
GDB after I get the "Thread 1" warning, I can then hit c to continue the process and it works with no issue. I can
then set the breakpoint again and hit it multiple times without causing the "Thread 1" warning/crash. This is pretty
weird. Have you seen anything like that?
After encountering this phenomenon, I then decided to not set the breakpoint until after the program has been running.
So I let it run, then hit ctrl-c to break the operation in GDB. Hitting break caused the "Thread 1" error and I had to
kill GDB. Once again, if I went back into GDB I was able to attach and debug with no issue.
As far as a watchdog timer, there isn't one running that I know of. In light of the experience I discussed above it
would seem that there isn't anything like a watchdog that is killing thread 1, it looks more like there is some other
miscommunication going on.
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/24/2009 8:58 PM
post25143
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Hello Christopher,
This will definitely help. Things are much clearer now: gdb,
for some reason, detaches from the process, or enters some
odd state, but your program does not die.
Could you, meanwhile, try the latest gdb? You can download
the updates from here:
http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.gdb
You can try the latest updates, both gdb 6.7 and gdb 6.8 and
let me know if they work better.
If they do, then all is fine; if they don't, could you do
the following after gdb gets into unresponsive state (and
you kill it): on your target, do a pidin threads on your
program:
# pidin -p <PID> threads
and post your output, I want to see if this is really odd
case of a process with thread with tid 1 being dead.
Thank you,
Aleksandar
Christopher Hitchcock wrote:
> New set of logs attached.
>
> The groups of logs are:
> --No breakpoint set
> --Breakpoint set
> --Reattaching to the process after you get the "Thread 1" error (see below)
>
> I verified that if the breakpoint was not set then the code functions normally.
>
> One interesting thing I found was that if I reattach to the process (since I started it on the host using "on -h")
using GDB after I get the "Thread 1" warning, I can then hit c to continue the process and it works with no issue. I
can then set the breakpoint again and hit it multiple times without causing the "Thread 1" warning/crash. This is
pretty weird. Have you seen anything like that?
>
> After encountering this phenomenon, I then decided to not set the breakpoint until after the program has been running.
So I let it run, then hit ctrl-c to break the operation in GDB. Hitting break caused the "Thread 1" error and I had
to kill GDB. Once again, if I went back into GDB I was able to attach and debug with no issue.
>
> As far as a watchdog timer, there isn't one running that I know of. In light of the experience I discussed above it
would seem that there isn't anything like a watchdog that is killing thread 1, it looks more like there is some other
miscommunication going on.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25131
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/24/2009 10:23 PM
post25145
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Hello Christopher,
I have reproduced the problem locally; updates available on
the web will not help, sorry.
I will open a PR on this and fix it; I will inform you here
when a new update containing the fix becomes available.
Thank you for your effort and sorry for the inconvenience.
---
Aleksandar
Aleksandar Ristovski wrote:
> Hello Christopher,
>
> This will definitely help. Things are much clearer now: gdb, for some
> reason, detaches from the process, or enters some odd state, but your
> program does not die.
>
> Could you, meanwhile, try the latest gdb? You can download the updates
> from here:
> http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.gdb
> You can try the latest updates, both gdb 6.7 and gdb 6.8 and let me know
> if they work better.
>
> If they do, then all is fine; if they don't, could you do the following
> after gdb gets into unresponsive state (and you kill it): on your
> target, do a pidin threads on your program:
>
> # pidin -p <PID> threads
>
> and post your output, I want to see if this is really odd case of a
> process with thread with tid 1 being dead.
>
> Thank you,
>
> Aleksandar
>
>
> Christopher Hitchcock wrote:
>> New set of logs attached.
>>
>> The groups of logs are:
>> --No breakpoint set
>> --Breakpoint set
>> --Reattaching to the process after you get the "Thread 1" error (see
>> below)
>>
>> I verified that if the breakpoint was not set then the code functions
>> normally.
>>
>> One interesting thing I found was that if I reattach to the process
>> (since I started it on the host using "on -h") using GDB after I get
>> the "Thread 1" warning, I can then hit c to continue the process and
>> it works with no issue. I can then set the breakpoint again and hit
>> it multiple times without causing the "Thread 1" warning/crash. This
>> is pretty weird. Have you seen anything like that?
>>
>> After encountering this phenomenon, I then decided to not set the
>> breakpoint until after the program has been running. So I let it run,
>> then hit ctrl-c to break the operation in GDB. Hitting break caused
>> the "Thread 1" error and I had to kill GDB. Once again, if I went
>> back into GDB I was able to attach and debug with no issue.
>>
>> As far as a watchdog timer, there isn't one running that I know of.
>> In light of the experience I discussed above it would seem that there
>> isn't anything like a watchdog that is killing thread 1, it looks more
>> like there is some other miscommunication going on.
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post25131
>
>
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/24/2009 11:13 PM
post25149
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Hello Christopher,
Could you try attached gdb? Note it is a binary built on my
machine and therefore unsupported. New update will contain
the fix, and I will make sure we post an update soon.
If you get a chance to try this gdb, please let me know if
it worked for you.
Thank you,
Aleksandar
Aleksandar Ristovski wrote:
> Hello Christopher,
>
> I have reproduced the problem locally; updates available on the web will
> not help, sorry.
>
> I will open a PR on this and fix it; I will inform you here when a new
> update containing the fix becomes available.
>
> Thank you for your effort and sorry for the inconvenience.
>
> ---
> Aleksandar
>
>
> Aleksandar Ristovski wrote:
>> Hello Christopher,
>>
>> This will definitely help. Things are much clearer now: gdb, for some
>> reason, detaches from the process, or enters some odd state, but your
>> program does not die.
>>
>> Could you, meanwhile, try the latest gdb? You can download the updates
>> from here:
>> http://community.qnx.com/sf/frs/do/listReleases/projects.toolchain/frs.gdb
>>
>> You can try the latest updates, both gdb 6.7 and gdb 6.8 and let me
>> know if they work better.
>>
>> If they do, then all is fine; if they don't, could you do the
>> following after gdb gets into unresponsive state (and you kill it): on
>> your target, do a pidin threads on your program:
>>
>> # pidin -p <PID> threads
>>
>> and post your output, I want to see if this is really odd case of a
>> process with thread with tid 1 being dead.
>>
>> Thank you,
>>
>> Aleksandar
>>
>>
>> Christopher Hitchcock wrote:
>>> New set of logs attached.
>>>
>>> The groups of logs are:
>>> --No breakpoint set
>>> --Breakpoint set
>>> --Reattaching to the process after you get the "Thread 1" error (see
>>> below)
>>>
>>> I verified that if the breakpoint was not set then the code functions
>>> normally.
>>>
>>> One interesting thing I found was that if I reattach to the process
>>> (since I started it on the host using "on -h") using GDB after I get
>>> the "Thread 1" warning, I can then hit c to continue the process and
>>> it works with no issue. I can then set the breakpoint again and hit
>>> it multiple times without causing the "Thread 1" warning/crash. This
>>> is pretty weird. Have you seen anything like that?
>>>
>>> After encountering this phenomenon, I then decided to not set the
>>> breakpoint until after the program has been running. So I let it
>>> run, then hit ctrl-c to break the operation in GDB. Hitting break
>>> caused the "Thread 1" error and I had to kill GDB. Once again, if I
>>> went back into GDB I was able to attach and debug with no issue.
>>>
>>> As far as a watchdog timer, there isn't one running that I know of.
>>> In light of the experience I discussed above it would seem that there
>>> isn't anything like a watchdog that is killing thread 1, it looks
>>> more like there is some other miscommunication going on.
>>>
>>> _______________________________________________
>>> General
>>> http://community.qnx.com/sf/go/post25131
>>
>>
>
>
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/25/2009 9:31 AM
post25172
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Thanks for the quick turn-around on this! I really appreciate the help you've been providing.
That seems to work for the most part. The first time it hits the breakpoint, I still see the Thread 1 warning, but it
looks like GDB re-queries the threads and grabs the next available one. So the breakpoint doesn't trigger, but the
environment is still up and running. The next time my program hits the breakpoint it works fine.
I was able to repeat this same experience using the IDE and the dev GDB. I still get the warning in GDB about the
breakpoint being an "unresolved breakpoint". However I can actually debug now after the breakpoint is hit once. The
only problem now is that GDB doesn't actually break on the breakpoint the first time.
I'm still curious as to why it looks like Thread 1 dies like that. Any ideas?
I've attached the logs from running your dev build of GDB.
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/25/2009 9:59 AM
post25177
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
The Thread 1 warning can be ignored, in fact I will be
removing it since it introduces confusion. One scenario in
which thread 1 exits (and may look like it reappears again
later) may happen if you are using thread pools.
You are right with your observation: if gdb tries to select
thread 1, and it does not exist, the next available will be
selected. This, however, does not explain missing the
breakpoint for the first time. I did not reproduce that
here, it works for me.
However, there are two things that still confuse me:
1) "unresolved breakpoint" message, I do not see it in the logs.
2) From the log you provided, it doesn't look like it missed
the breakpoint? It looks like it does get hit and it stops
at it:
Temporary breakpoint 2, main (nto:
nto_fetch_registers(regcache 012d4f30 ,regno 11)
nto: set_thread(th 1 pid 327704, prev tid 1)
argc=1, argv=0xffe14)
at
C:/projects/gen2sdk/Libraries/sms/app/platform/QNX/DM355EVx/SmsApp_dm355-evx.c:53
53 bOsalStarted = OSAL.bStart(100, bBootStrap, NULL);
Continuing.
....
nto: nto_insert_breakpoint(addr 00109b5c, contents_cache
012D508C) <<<<<<<<<<<<<<<<< your breakpoint
infrun: TARGET_WAITKIND_STOPPED
nto: nto_fetch_registers(regcache 012d4f30 ,regno 15)
nto: set_thread(th 4 pid 327704, prev tid 4)
infrun: stop_pc = 0x109b5c <<<<<<<<<<<<<<<<<<<<<< your
breakpoint
...
Breakpoint 1, vCreateCmdHandler ()
at
C:/Projects/gen2sdk/Libraries/sms/cli/source/sms_debug.c:1692
1692 pcCmdLine = SMSD_pcTokenizeString( (char*)NULL,
acTokens, eDefaultStrFormat );
Continuing.
Could you explain this in more detail?
Thanks,
Aleksandar
Christopher Hitchcock wrote:
> Thanks for the quick turn-around on this! I really appreciate the help you've been providing.
>
> That seems to work for the most part. The first time it hits the breakpoint, I still see the Thread 1 warning, but it
looks like GDB re-queries the threads and grabs the next available one. So the breakpoint doesn't trigger, but the
environment is still up and running. The next time my program hits the breakpoint it works fine.
>
> I was able to repeat this same experience using the IDE and the dev GDB. I still get the warning in GDB about the
breakpoint being an "unresolved breakpoint". However I can actually debug now after the breakpoint is hit once. The
only problem now is that GDB doesn't actually break on the breakpoint the first time.
>
> I'm still curious as to why it looks like Thread 1 dies like that. Any ideas?
>
> I've attached the logs from running your dev build of GDB.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25172
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/25/2009 12:07 PM
post25198
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
[Unresolved breakpoint warning]
The unresolved breakpoint warning shows up in the IDE under the "Problems" tab at the bottom of the screen. I'm not
sure where that warning comes from since I don't see anything about it in the verbose GDB log. Maybe it is an IDE issue
?
[Breakpoint not stopping the first time]
I ran the test again and confirmed that the breakpoint I set is not triggered the first time through. I attached a copy
of what I saw on the command prompt. As you can see in the attached log, I never issued the continue command and it
doesn't show the breakpoint being hit. At line 29 is where I think it was when it should have hit the breakpoint. I
had to hit CTRL-C two or three times to break into GDB and quit the debugger.
Looking at the gdbsession.log from the last post, it does seem to show that the breakpoint was hit and it continued,
however I never issued the continue command.
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/25/2009 2:06 PM
post25220
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
From the log I don't see anything odd. I see two
breakpoints set:
nto: nto_insert_breakpoint(addr 01038fb4, contents_cache
0114BCD4)
nto: nto_insert_breakpoint(addr 00109b5c, contents_cache
012CF0E4)
and both seem to be correct: 0x01038fb4 is temporary at
main, and 0x00109b5c is in your code.
Do you restart your program when you try this exercise? Note
that exiting gdb after attaching to a process defaults to
detaching from the process (and letting it run). Make sure
you start new process (with "on -h") every time you are
testing this issue. (and before quitting gdb, issue a "kill"
command, or kill the process from your terminal before
restarting new session).
Thanks,
Aleksandar
Christopher Hitchcock wrote:
> [Unresolved breakpoint warning]
> The unresolved breakpoint warning shows up in the IDE under the "Problems" tab at the bottom of the screen. I'm not
sure where that warning comes from since I don't see anything about it in the verbose GDB log. Maybe it is an IDE issue
?
>
> [Breakpoint not stopping the first time]
> I ran the test again and confirmed that the breakpoint I set is not triggered the first time through. I attached a
copy of what I saw on the command prompt. As you can see in the attached log, I never issued the continue command and
it doesn't show the breakpoint being hit. At line 29 is where I think it was when it should have hit the breakpoint. I
had to hit CTRL-C two or three times to break into GDB and quit the debugger.
>
> Looking at the gdbsession.log from the last post, it does seem to show that the breakpoint was hit and it continued,
however I never issued the continue command.
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25198
>
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/25/2009 2:32 PM
post25225
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
> From the log I don't see anything odd. I see two
> breakpoints set:
>
> nto: nto_insert_breakpoint(addr 01038fb4, contents_cache
> 0114BCD4)
> nto: nto_insert_breakpoint(addr 00109b5c, contents_cache
> 012CF0E4)
Yeah, and it will hit my breakpoint (not the temp one)the second time I come across it, just not the first time.
>
> Do you restart your program when you try this exercise?
>
>
Each time I run a test I:
--Quit GDB
--Kill my app process
--Kill pdebug
I get a little kill happy.
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/25/2009 4:26 PM
post25254
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Ok, thanks.
I will have to reproduce this situation here.
I will let you know as soon as I have something new.
Meanwhile, I hope you can do your work knowing all the
caveats and workarounds.
Thank you,
Aleksandar
Christopher Hitchcock wrote:
>> From the log I don't see anything odd. I see two
>> breakpoints set:
>>
>> nto: nto_insert_breakpoint(addr 01038fb4, contents_cache
>> 0114BCD4)
>> nto: nto_insert_breakpoint(addr 00109b5c, contents_cache
>> 012CF0E4)
>
> Yeah, and it will hit my breakpoint (not the temp one)the second time I come across it, just not the first time.
>
>> Do you restart your program when you try this exercise?
>>
>>
> Each time I run a test I:
> --Quit GDB
> --Kill my app process
> --Kill pdebug
>
> I get a little kill happy.
>
>
>
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25225
>
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/26/2009 11:28 AM
post25359
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Hello Christopher,
I reproduced the issue. I believe it is fixed now.
Please try the attached gdb.
Thanks,
Aleksandar
Aleksandar Ristovski wrote:
> Ok, thanks.
>
> I will have to reproduce this situation here.
>
> I will let you know as soon as I have something new.
>
> Meanwhile, I hope you can do your work knowing all the caveats and
> workarounds.
>
> Thank you,
>
> Aleksandar
>
> Christopher Hitchcock wrote:
>>> From the log I don't see anything odd. I see two breakpoints set:
>>>
>>> nto: nto_insert_breakpoint(addr 01038fb4, contents_cache 0114BCD4)
>>> nto: nto_insert_breakpoint(addr 00109b5c, contents_cache 012CF0E4)
>>
>> Yeah, and it will hit my breakpoint (not the temp one)the second time
>> I come across it, just not the first time.
>>
>>> Do you restart your program when you try this exercise?
>>>
>> Each time I run a test I:
>> --Quit GDB
>> --Kill my app process
>> --Kill pdebug
>>
>> I get a little kill happy.
>>
>>
>>
>>
>> _______________________________________________
>> General
>> http://community.qnx.com/sf/go/post25225
>>
>
>
|
|
|
Christopher Hitchcock
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Christopher Hitchcock
03/26/2009 12:26 PM
post25368
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
That looks like it works now. Thanks! The breakpoint correctly stops the first time.
The IDE still seems to get out of sync however. See the attached screenshot. Each time I start the debugger it seems
to duplicate my breakpoint. As you can see in the breakpoint list in the screenshot it shows I have four breakpoints
set for line 1692. This doesn't seem to affect operation, but it clutters the interface.
That unresolved breakpoint warning still shows up the first time I set a breakpoint. However, like the duplicating
breakpoints, it doesn't affect operation.
|
|
|
Aleksandar Ristovski(deleted)
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
|
Aleksandar Ristovski(deleted)
03/26/2009 12:30 PM
post25370
|
Re: Unresolved Breakpoint warning in IDE 4.5 Tau
Ok, this might be an IDE issue.
Could you provide a few more detail about this particular
situation?
When in IDE, in the state as in the picture, could you type
in gdb console:
info b
and post the result? I want to see if IDE mistakenly issues
two (or more) "-insert-break" commands to GDB.
If so, then this is for IDE people (and I am sure someone
from IDE team will join us here...)
Thanks,
Aleksandar
Christopher Hitchcock wrote:
> That looks like it works now. Thanks! The breakpoint correctly stops the first time.
>
> The IDE still seems to get out of sync however. See the attached screenshot. Each time I start the debugger it seems
to duplicate my breakpoint. As you can see in the breakpoint list in the screenshot it shows I have four breakpoints
set for line 1692. This doesn't seem to affect operation, but it clutters the interface.
>
> That unresolved breakpoint warning still shows up the first time I set a breakpoint. However, like the duplicating
breakpoints, it doesn't affect operation.
>
> _______________________________________________
> General
> http://community.qnx.com/sf/go/post25368
>
>
> ------------------------------------------------------------------------
>
|
|
|
|