foundry27 : Post

Forum Topic - Unresolved Breakpoint warning in IDE 4.5 Tau: Page 1 of 2 (30 Items)

View: as

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)

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

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.

Attachment:

verbose_gdb_log.txt 15.08 KB

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

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)

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

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?

Attachment:

gdb logs.zip 1.19 KB

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

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)

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

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")

Attachment:

gdb logs.zip 2.64 KB

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

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.

Attachment:

GDBLogs.zip 20.37 KB

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
>>
>>
> 
>

Attachment:

ntoarm-gdb.zip 2.65 MB

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.

Attachment:

NewGDBLogs.zip 4.81 KB

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

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.

Attachment:

GDB_STDOUT.txt 3.07 KB

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

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
>>
> 
>

Attachment:

ntoarm-gdb.zip 2.65 MB

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.

Attachment:

IDEScreenShot.JPG 190.75 KB

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
> 
> 
> ------------------------------------------------------------------------
>

Return

The text you entered is not a valid object ID
More Information
Object IDs begin with an object prefix and end with a number. For example, if you enter
artf2345
the application will jump directly to an artifact with the ID artf2345. Some valid object prefixes are:
artf	for an artifact
doc	for a document
page	for a project page
topc	for a discussion topic
wiki	for a wiki page