#29 avarice segmentation fault

[Mate Varga]

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

[Joerg Wunsch]

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

[Mate Varga]

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)

[Joerg Wunsch]

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.

[Mate Varga]

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

[Joerg Wunsch]

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.

[Mate Varga]

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?

[Mate Varga]

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

[Mate Varga]

Do you have any idea?

[Joerg Wunsch]

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.

[Mate Varga]

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

[Joerg Wunsch]

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.

[Mate Varga]

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

[Mate Varga]

Or maybe should I try an older version of avarice?

[Joerg Wunsch]

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.

[Mate Varga]

hello,

Is there any update?

Thanks.

Best regards,
Mate

[Joerg Wunsch]

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.

[Kamil Lewandowski]

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

[Joerg Wunsch]

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.

[Joerg Wunsch]

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.

[Joris Putcuyps]

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)

[Joris Putcuyps]

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

[Joris Putcuyps]

I've attached Kamil's patch.

[DySprozin]

@kaml
Many thanks for the patch! Its working! Awesome!!!