[bug #29] avarice segmentation fault

[avrs-admin]

faeren03 2020-09-19 07:33:42.556000

Hello,

I have a problem using avr-gdb with avarice on an Atmega32. Stopping, normal stepping, continuing without breakpoints works fine. But when I add a breakpoint and continue the execution of the code then I receive this Segmentation fault (core dumped) error. When I try to step out of a function then I also receive this Segmentation fault (core dumped) error.

See pictures attached.

Do you have any idea why?

Thank you very much!

Best regards, Mate Varga

backtrace.png output.txt gdbbt.png avarcompiled1.png avarcompiled2.png avariceownbuildoutput.png gflag.png fix_jtag1_breakpoints_crash.patch

This issue was migrated from https://sourceforge.net/p/avarice/bugs/29/

[avrs-admin]

joerg_wunsch 2020-09-19 22:20:15.894000

Well, a lot of information is missing.

• What kind of debug adapter is used, what's the exact commandline to start AVaRICE?
• Ideally, I'd be interested in a stack trace from the coredump; GDB can be used to analyze the coredump file

[avrs-admin]

faeren03 2020-09-20 08:15:00.733000

I'm trying to make this work on an Arch Linux. I'm using the following command: avarice -1 -j /dev/ttyUSB0 :4242 -P atmega32 -d So I'm using an mKI adapter. I just attached the whole output of AVaRICE.

How can I check the backtrace with avr-gdb? Because after the "Segmentation fault" I can't check backtrace I just got "No stack." error message. (see picture attached)

[avrs-admin]

joerg_wunsch 2020-09-20 12:45:53.068000

OK, an old ("mkI") - I don't have one here readily available for testing. Maybe I can jumper some compatible clone on an STK500. In order to debug AVaRICE, you have to run it under control of the host system's GDB (not AVR-GDB). Just start it (in a separate terminal window) like

gdb avarice
(gdb) run -1 -j /dev/ttyUSB0 :4242 -P atmega32 -d

then connect AVR-GDB to it. Once it crashed, type

bt

in that GDB window.

[avrs-admin]

faeren03 2020-09-20 13:04:41.653000

Thank you very much, that would be great! Please see the bt output attached.

[avrs-admin]

joerg_wunsch 2020-09-20 19:46:21.391000

Unfortunately, I forgot: without AVaRICE having full debugging symbols, the stack trace is pretty useless. :-( Can you compile AVaRICE yourself from sourcecode? If so, please re-run the test, and use the in-tree version (rather than an installed one) for the stack trace.

[avrs-admin]

faeren03 2020-09-20 21:16:28.434000

No problem. I have a compiled one in my Downloads folder. It seems that I have the same output that way. Am I using the command correctly to startup gdb with avarice?

[avrs-admin]

faeren03 2020-09-20 21:22:15.970000

Ah sorry I used the wrong one. Now it seems I have something readable.

[avrs-admin]

faeren03 2020-09-22 21:04:59.997000

Do you have any idea?

[avrs-admin]

joerg_wunsch 2020-09-23 05:27:35.008000

Offhand not. The stack trace has symbols now, but it lacks debugging symbols (compiler option -g). Unfortunately, jtag::layoutBreakpoints() performs a lot of actions on arrays where a memory access violation could happen. Can you verify your compilation included a -g option?

I'm afraid I first have to build my own ICE for that.

[avrs-admin]

faeren03 2020-09-24 15:50:13.690000

Yes it is included. Am I need to load the .elf file symbols somehow? Because If I execute these command, the .elf file is not referenced.

gdb avarice (gdb) run -1 -j /dev/ttyUSB0 :4242 -P atmega32 -d

[avrs-admin]

faeren03 2020-09-24 15:56:22.826000

Or maybe should I try an older version of avarice?

[avrs-admin]

joerg_wunsch 2020-09-24 17:39:33.189000

Turn that "gdb avarice" into a "gdb ./path/to/your/compiled/avarice". I'm afraid you might debug the one found in $PATH rather than your compilation.

[avrs-admin]

joerg_wunsch 2020-09-24 17:41:03.581000

Nope, the current version is supposed to support the "MkI" version, so we either have to declare it unsupported (and refer to an older version then), or we fix the bug. I'd prefer the latter, and as such, your bug report is welcome. But unless you can trace that yourself completely down to the respective source code line, I have to reproduce it first.

[avrs-admin]

faeren03 2020-09-24 19:34:01.237000

Ah yes, sorry, I tried with direct path like you wrote now. I just copy pasted what you wrote before.

[avrs-admin]

faeren03 2020-09-30 20:54:00.468000

hello,

Is there any update?

Thanks.

Best regards, Mate

[avrs-admin]

joerg_wunsch 2020-09-30 20:57:52.597000

Sorry, since your trace doesn't have debugging symbols - I need to build my own mkI ICE clone first, and then try reproducing the error.

[avrs-admin]

kaml 2020-10-01 16:48:39.418000

Hi, I have the same problem too. I was able to track down the problem. The problem is that for JtagICE mk1 in the jtag1 class there are 3 methods for handling breakpoints: addBreakpoint, deleteBreakpoint, updateBreakpoints. updateBreakpoint for jtag1 uses its own structures filled with addBreakpoint and deleteBreakoint, and should use the "bp" structure. The quickest fix for this error will be:

--- a/avarice/src/jtag.h     2020-10-01 18:42:10.267554671 +0200
+++ b/avarice/src/jtag.h  2020-10-01 18:43:28.447174612 +0200
@@ -872,10 +872,10 @@
   virtual void deleteAllBreakpoints(void) = 0;

   /** Delete breakpoint at the specified address. */
-  bool deleteBreakpoint(unsigned int address, bpType type, unsigned int length);
+  virtual bool deleteBreakpoint(unsigned int address, bpType type, unsigned int length);

   /** Add a code breakpoint at the specified address. */
-  bool addBreakpoint(unsigned int address, bpType type, unsigned int length);
+  virtual bool addBreakpoint(unsigned int address, bpType type, unsigned int length);

   bool layoutBreakpoints(void);

Or rewrite the updateBreakpoints method in jtag1 class.

Regards Kamil

[avrs-admin]

joerg_wunsch 2020-10-01 18:55:26.443000

Thanks for the analysis! My own mkI clone is still on its way, once here, I'll test that. @Mate Varga: the fix will the surely be in the next release (whenever that will happen ;). For the time being, you could try whether Kamil's fix solves your issue.

[avrs-admin]

joerg_wunsch 2020-10-12 19:38:37.520000

• status: open --> accepted
• assigned_to: Joerg Wunsch

[avrs-admin]

joerg_wunsch 2020-10-12 19:38:38.218000

My own JTAGICEmkI clone is ready now. However, I cannot seem to make it stop at any breakpoint. I don't have the time to track that down right now, but will for sure keep the bug report open so it can be fixed before the next release.

[avrs-admin]

jputcu 2021-08-29 12:37:51.832000

I just did a small test with my Olimex Jtag mkI on Manjaro linux and also get the segmentation fault. Will see if Kamil's fix solves it.

Program received signal SIGSEGV, Segmentation fault.
0x0000555555593cb3 in jtag::layoutBreakpoints (this=this@entry=0x5555556d92e0) at   jtaggeneric.cc:878
878     if (deviceDef->device_flags == DEVFL_NO_SOFTBP)

[avrs-admin]

jputcu 2021-08-29 13:28:54.028000

Kamil's fix does solve the segmentation fault and I agree with the explanation and patch.

[avrs-admin]

jputcu 2021-09-07 18:37:41.360000

I've attached Kamil's patch.

[avrs-admin]

jputcu 2021-09-14 18:17:30.044000

• status: accepted --> closed-fixed