eeschema often segfaults hitting C on a component to duplicate

[Lorenzo Marcantonio]

On today's git pull, but probably even from before, sometime hitting C on a component to duplicate it causes a segfault, especially if it was recently modified in the symbol editor.

Difficult to reproduce, I'll try to obtain a stack trace.

[Nick Østergaard (nickoe)]

Just as a tip, if you have coredumpctl enabled our your system you can recall recent coredumps with the tool, suh that you do not need to run your session in gdb directly.

This may also give you clues on how to reproduce more consistently.

[Wayne Stambaugh (stambaughw)]

Please include your version information. There have been a lot of bug fixes recently for the symbol library editor so the but may already have been fixed but there is no way of knowing without the kicad version information.

[Maciej Suminski (orsonmmz)]

Lorenzo,

The bug you have reported sounds like a serious issue that we need to address before releasing v5. I think you are the only person being able to reproduce it, therefore we would be thankful for a few more details. The most appreciated would be a backtrace illustrating the crash, but any other information might be helpful too (actions to reproduce; does it happen on all schematics? if not, what is so special about ones that lead to a crash?)

[Lorenzo Marcantonio (l-marcantonio)]

I tried valgrind and it sometimes reports reads of freed space; probably some old pointer is hanging around; however my version is now quite old. So my plan is:
1) a git pull
2) a full debug build
3) re-run under valgrind (painful)
4) profit (I expect usable backtraces from memcheck...)

[Lorenzo Marcantonio (l-marcantonio)]

OK, it seems I was more or less on the right track. Workflow tried: open eeschema, load a schematic then the symbol editor.

Load a symbol (I tried on the 74125 since I hate that buffer for some reason) rename it, save the lib with the toolbar button.

Fun thing: it crashed when I accidentally hit the wheel and zoomed in/out.

Things I can observe from the valgrind log:

- Just *opening* the symbol editor triggers LIB_EDIT_FRAME::OnUpdateSaveLib; LIB_EDIT_FRAME::OnUpdatePartModified probably follows. This is strange in itself.

- The undo machinery (LIB_EDIT_FRAME::OnUpdateUndo) is using freed data from the part manager; ClearDeletedBuffer in SaveLibrary seems the culprit;

- All the following issues and ultimately the crash seem to come from the same data. So, just guessing, either we delete live data or we don't update the view (in this case) with the most recent one.

Hope this helps, can do other trials if needed

[Maciej Suminski (orsonmmz)]

Lorenzo, many thanks for the report, I will try to reproduce the steps here. BTW. much less painful is to use the address sanitizer, available both in gcc and clang (add -fsanitize=address to compile flags).

[Maciej Suminski (orsonmmz)]

I managed to reproduce the crash you described, but note it is different than what you have described in the original report. Can you still reproduce crash while duplicating a component?

[Maciej Suminski (orsonmmz)]

Lorenzo, I have pushed a fix for the symbol rename crash. I have not marked the bug report as 'fixed' as the patch does not fix the original issue. I revert the report status to 'incomplete' as we do not have much details about the original problem (crash on component duplicate).

[Lorenzo Marcantonio (l-marcantonio)]

I hoped that there were only one bug causing the instabilities. I'll try to reproduce the duplicating issue *without* applying the patch (otherwise it would be impossible to duplicate if it indeed was from the same problem!)

[Lorenzo Marcantonio (l-marcantonio)]

OK, I tripped another one trying to replicate the 'original' use case: created a new symbol in the library, placed it and tried to duplicate id. Well, almost, instead of C for duplicate I hit M for move and it triggered anyway...

I'd say that most of the errors are from the presumably-ffxed PART_BUFFER freed memory usage, so there is hope. The fatal one however is most puzzling since it's from wxSocket accessing a completely invalid address. Maybe some runaway write pointer?

To crosscheck I'll pull the patch and retry. With some luck everything is cascaded from the original issue.

[Maciej Suminski (orsonmmz)]

I tried to replicate the problem, but it works stable here (6b9a286a and later). Please verify, this one is really important.

[Lorenzo Marcantonio (l-marcantonio)]

I used eeschema all yesterday under valgrind but not one segfault or invalid access detected, even after doing extensive symbol editing. It seems that the PART_BUFFER deletion was the root of the evil.

I'd mark this as fix committed, your call. Good work

[Maciej Suminski (orsonmmz)]

Great! Many thanks both for the report and further tests.