GDB Error

[lpcware]

Content originally posted in LPCWare by dustinkasel on Thu Mar 20 10:38:57 MST 2014
I am trying to debug a program I've been working with for months and recently came across what appears to be a strange bug in LPCXpresso. Upon completion of flash download, arm-none-eabi-gdb.exe stops working and needs to close, per Windows. My options are to debug or close the program and as far as I can tell this executable was built without debug capabilities so debug provides no insight.

I am running LPCXpresso v7.02 on Windows 8.1 64-bit.

See the attached screenshot for more info on the error that LPCXpresso presents once arm-none-eabi-gdb shuts down.

Any insight would be much appreciated!

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Nov 14 01:40:12 MST 2014
If you look in your .map file, you will see a list of the code that has been removed (because it is unused). In there, you will notice that Timer0Match0IT() has been removed - because it is never called from your application. This is the reason for the GDB crash.

Obviously, the crash should not be happening, and we are working with ARM to resolve that, but if you were able to set the breakpoint, it would never be hit as the function would never be called.

To workaround this issue, either
- do not set breakpoints on code that is never called, and thus has been removed, or
- remove the "gc-sections" option from the linker settings, to stop unused code being removed (making your application larger than it needs to be). For more information, see: http://www.lpcware.com/content/faq/lpcxpresso/unused-section-elimination

[lpcware]

Content originally posted in LPCWare by Bela on Thu Nov 13 11:05:45 MST 2014
Yes, I'm in the project I sent.

I try to insert a breakpoint in line 113 and later in line 115. ( Timer0Match0IT ).

I also have an idea: maybe, this function is never called? It must be - as it's name suggests - a service routine for Timer0 Match0. But, if I think it good, I still have to write an IT service routine for Timer0 IT ( I still have to find the correct name for this function), there I have to poll the reason why I do have a Timer0 IT and then shall I call this function.
In case I'm right, some error message is legal.
But why do I have the GDB error?

I also attach two screenshors. Please have a look at them. Are there everything all right? What does mean the
' make: *** [main.o] Error 1 C/C++ Problem '   ?

On the other screenshot, is it legal to have so many times the ' Proba03.axf ... ' and Proba03 ' Debug ... ' lines?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Nov 13 10:49:01 MST 2014
OK, so this IS the 'GDB Error'

So where are you setting the breakpoint that causes it to crash? Assuming the is the project you sent earlier?

[lpcware]

Content originally posted in LPCWare by Bela on Thu Nov 13 10:42:03 MST 2014
Oooops, .... pardon:

I cleanded up the project.
I removed all the breakpoints.
I skipped the debug symbols.

Then I set a breakpoint because I'd like to debug my code (it doesn't do what I expected). Only one breakpoint is set.
Then I clicked on 'debug' .
Compiled succesfully, downloaded successfully.
I click on the 'resume [F8]' icon. My program seems to be run, but doesn't do what I expect.
Now, I click on the margin to set a breakpoint.
The GDB error comes immediately.

When I set a breakpoint prior to click on the 'debug' icon, the same GDB error comes during the download to flash.

Here's what I got:

/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names.suffix != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names.suffix != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Nov 13 10:40:21 MST 2014
You have NOT got the 'GDB error'.

Instead, GDB is reporting that you have got a Hard Fault in your application. Suggest you read this FAQ on debugging a hard fault:
http://www.lpcware.com/content/faq/lpcxpresso/debugging-hard-fault

However, the cause of this is that you have not enabled TIMER2. If you look in the Peripherals view, you will see TIMER2 is grayed-out, meaning it is disabled. If you try to access the registers of a disabled peripheral, you will get a Hard Fault.

[lpcware]

Content originally posted in LPCWare by Bela on Thu Nov 13 10:28:52 MST 2014
I'm sorry gentlemen, I found my failure.
I tried to setup Timer2 and Timer3 but they are not powered up. This has made a hard fault.

Sorry again.

[lpcware]

Content originally posted in LPCWare by Bela on Thu Nov 13 10:15:58 MST 2014
Gentlemen,

in my case this GDB error is permanent.
I use LPCXpresso 7.5.0 [Build 254] on Ubuntu 14.04.
Since my project is not confidential, I attached it here.
The symptom is: I can compile this project and I can download it onto my LPCXpesso LPC1768 board. But it doesn't run. If I try to single-step, I got the GDB error when I reach Timer2Setup() in the 'main' function. In this function, the LPC_TIMER2->CCR = 0; instruction results a hard fault.

Please consider, I'm just a novice user, please don't laugh too loud :-)

What I already tried: Run/Remove all breakpoint 
Right click on lpc_chip_175x_6x / libs / libusbd_175x_6x_lib.a and Binary utilities -> Strip debug symbols.

I also tried to clean up project and than compile it again and download it.

The project has been created by Project wizzard, to my best knowledge I didn't change any settings.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Nov 07 18:44:16 MST 2014
It is quite possible that it is not setting the breakpoint on that line of code (which may not have been removed) but it triggers the bug elsewhere.

As I said, if this problem occurs, you should remove all breakpoints and then restart you debug session.

In our experience, this is a VERY rare problem, so I am vry surprised that you are hitting it so often.

One other possible way to avoid this problem is to strip the debug symbol information from any libraries that you are using (and not wishing to debug). You can do this as follows:
- LPCXpresso v7.5.0 - right click on the library in Project Explorer and select Binary utilities->Strip debug symbols
- previous versions, find the library and run the following command:
arm-none-eabi-objcopy -g libraryname.lib

[lpcware]

Content originally posted in LPCWare by thommaughan on Thu Nov 06 21:30:22 MST 2014
I can try to set a breakpoint by double-clickng the margin, HOWEVER, I am seeing this gdb error frequently when I do so - I'm surprised that the linker is removing so much code, statments like:

while(!uart_transmit_complete());

are causing the error and I'd be quite surprised if the linker could remove these kinds of statements, maybe I'm misunderstanding something about your post.   At this point I've got data flowing out the serial port and am making great progress without much need for breakpoints.  At the times I do need breakpoints, it's quite painful to be hitting this gdb bug.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Nov 03 22:31:55 MST 2014
You can set a breakpoint at any time (i.e. double-click in the margin of the source file) - you don't have to be debugging.

When you start debugging, the debugger attempts to set every breakpoint in the target. When you stop debugging, (in effect) they are cleared from the target.

Unless you specifically clear a breakpoint, then the next time you start a debug session, the debugger will try to set it again. As breakpoints are associated with lines in a source file, they persist across IDE sessions. If you want to see what breakpoints are set, open the Breakpoints view (it is one of the views alongside the Quickstart panel)

[lpcware]

Content originally posted in LPCWare by thommaughan on Mon Nov 03 21:59:17 MST 2014
Thanks for the response - I will give your recommendation a try.  

I was not aware that breakpoints persisted after closing LPCXpresso, but if they do then that would explain the recurring failure.   Somehow breakpoints get cleared when changing to a different project...?   I'm still learning LPCXpresso (and Eclipse).

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Mon Nov 03 21:24:13 MST 2014
1) There really is no need to avoid setting breakpoints. Setting a breakpoint when the target is running has no affect on provoking the error. In fact, setting a breakpoint on a running target stops the target, sets the breakpoint and restarts the target again.

The error is actually provoked by setting a breakpoint on unused code that has been removed by the linker. This can happen with (for example) stale breakpoints from previous debug sessions. The simplest solution is to remove all breakpoints (from the Breakpoint view) and then reset those that you actually need.

We are working with ARM and the GDB maintainers to resolve this issue.

2) No need to do this. Just clear all the breakpoints and then reset those that you need,.

3) Again, no need to do this.

[lpcware]

Content originally posted in LPCWare by thommaughan on Mon Nov 03 19:55:16 MST 2014
Here's my workaround for the gdb crash.

1) avoid setting breakpoints, especially when the target is running.

2) if you set a breakpoint and then run and get the gdb fault:  Clear the breakpoint, terminate and exit and clear out all the error dialogs (exit LPCXpresso if necessary).  Then, select another project in the workspace and build and load it.   

3) then switch back to your project, build and debug it.   then for incremental code edits / debug, use a right click on the project as displayed in the debug tree view and select Terminate and Relaunch on the context menu - best to avoid setting breakpoints if you have 'a sensitive gdb'.

[lpcware]

Content originally posted in LPCWare by thommaughan on Mon Nov 03 17:59:47 MST 2014
I've been working with LPCXpresso for a few weeks.   I am now seeing the "arm-none-eabi-gdb.exe has stopped working" bug.

I have a modified version of the blinky example with an i2c device driver work in progress running on an LPC11U24 with code built for the LPC11U14.   I have set one breakpoint, but thought I'd cleared it.   I've shutdown LPCXpresso (LPCXpresso v7.4.0 [Build 229] [2014-09-16] ) and restarted, I've power cycled the target hardware,  I've disconnected and reconnected the LPC-Link2, I've rebooted my PC, still seeing the bug when trying to load code.  

The changes I made to my code were minor (changed an i2c address from 0x60 to 0x61).

Any idea if this is a bug addressed in an upcoming release?    I'll try to re-install the product, or perhaps find another PC and do a fresh install (groan).

Thanks in advance.

Here's the diagnostic output message from the LPCXpresso console:

$1 = 0xff
The target endianness is set automatically (currently little endian)
/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names.suffix != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) [answered Y; input not from terminal]
/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names.suffix != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) [answered Y; input not from terminal]

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

[lpcware]

Content originally posted in LPCWare by pnhnkvr on Thu May 15 09:15:26 MST 2014
How many enabled breakpoints? I experienced the same kind of problem when too many breakpoint was enabled.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue May 06 23:51:45 MST 2014
We have asked several times for details on how to reproduce this error....

[lpcware]

Content originally posted in LPCWare by brownm on Tue May 06 23:43:53 MST 2014
Using an Old GDB (or Toolchain) in the latest version of LPCXpresso didn't work.

We are going to try rolling back to a ver 6.x.x and see if it solves our issue.

[lpcware]

Content originally posted in LPCWare by brownm on Tue May 06 17:45:18 MST 2014
It appears there is a bug in ver 7.6 of GDB

GDB Bug

https://sourceware.org/bugzilla/show_bug.cgi?id=15468

This is the version of GDB that ships with LPCXpresso 7.1.1_125

I'm not sure how (of if) LPCXpresso are using the exact issue mentioned in the bug tracker - but it would be something to look at - the bug report mentions a workaround in GDB.

We are simply going to try rolling back to an earlier version of GDB from a previous LPCXpresso build and see what happens.....It indicated that the fault doesn't occur in earlier versions of GDB

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Mar 21 05:16:26 MST 2014
I've so far been unable to replicate your problem here.

If possible, can you export and post your project, so that we can built and test with it here.

http://www.lpcware.com/content/faq/lpcxpresso/how-importexport-projects

If not, then please ZIP up and post the map file generated by the linker when you build your code, plus the debug log from when you load your project and experience the crash.

http://www.lpcware.com/content/faq/lpcxpresso/debug-log

Can you also clarify - do you do anything between the flash download completing and the crash happening?

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by dustinkasel on Thu Mar 20 12:48:32 MST 2014
Zipping it worked. Thanks!

Now hopefully someone can provide insight into why the debugger is crashing. It seems unlikely that I could crash the debugger by making a code change.

By the way, this code is written for a LPC4088.