Segmentation fault (core dumped) since new version

[linuxmusician]

Hello i removed my old version of sequencer46 (version 0.92.something) via 'make uninstall' and installed the new verison via pacaur (using arch linux) Now when i: ~ click play twice ~ rigth click "new" ~ click play in qjackctl twice seq64 crashes with the error message "Segmentation fault (core dumped)". i tried to get more info by using -v but no difference.

[ahlstromcj]

So far I cannot replicate it on my setup. I notice it's an Arch build. You might check out this link and contact the author:

https://aur.archlinux.org/packages/sequencer64-git/

Can you give some more information about your setup? In the meantime, I will look at the Arch packaging noted above and check out its settings. Thanks for the report!

[ahlstromcj]

I checked out the commit noted in the package link above and built and tested it in the same way as the package, but could not replicate it.

[mxmilkiib]

I'm getting it here also, though no time to further bug test right now other than a quick qdb run on the clicking play twice gives me

Thread 1 "seq64" received signal SIGSEGV, Segmentation fault.
0x00007ffff4fed878 in gtk_container_remove () from /usr/lib/libgtk-x11-2.0.so.0

[ahlstromcj]

When you get a chance, let me know the version/commit, what is enabled (ALSA/JACK/Transport), other setup/build options, the desktop theme you're using, and if at all possible, a stack trace of the crash. Thanks!

[axelman0]

Also getting this issue. Happens with both "seq64" and "seq64 -mJt", with and without Hydrogen running alongside it. I'm also using Carla, Cadence, and Non Session Manager. Segfault occurs with the play button thing above as well as when double clicking on an empty pattern slot (or right clicking --> new)

EDIT: Manjaro, sequencer64-git-0.94.2.r1.ga7b03bf1-1 EDIT2: I tried cloning and running

git checkout 0dba5655 <-- 2017-12-11 version

and compiling it from there. This is a version that I am pretty sure I had before, and it no longer works (same segfault issue), which makes me think the problem is the recent Arch system updates and not Seq64 itself.

[ahlstromcj]

What distro are you using? Is it KXstudio? 32-bit or 64-bit.

I am still unable to replicate this bug. Thanks for any input you can give!

Chris

-------- axelman0 13:09 Sat 20 Jan --------

Also getting this issue. Happens with both "seq64" and "seq64 -mJt", with and without Hydrogen running alongside it. I'm also using Carla, Cadence, and Non Session Manager. Segfault occurs with the play button thing above as well as when double clicking on an empty pattern slot (or right clicking --> new)

— You are receiving this because you commented. Reply to this email directly, [1]view it on GitHub, or [2]mute the thread.

Reverse link: [3]unknown

References

Visible links

1. https://github.com/ahlstromcj/sequencer64/issues/128#issuecomment-359202279
2. https://github.com/notifications/unsubscribe-auth/AHnVqM8nr-g5j5nyhvxqG34TQ1sdR80Dks5tMlXtgaJpZM4RdKHd
3. https://github.com/ahlstromcj/sequencer64/issues/128#issuecomment-359202279

-- The camel died quite suddenly on the second day, and Selena fretted sullenly and, buffing her already impeccable nails -- not for the first time since the journey begain -- pondered snidely if this would dissolve into a vignette of minor inconveniences like all the other holidays spent with Basil. -- Winning sentence, 1983 Bulwer-Lytton bad fiction contest.

[ahlstromcj]

Still not able to duplicate it. I protected some additional pointer accesses with a not_nullptr() check, just to be more thorough, so check out master 0.94.3 now and see if it fixes anything. By the way, building the code in a KXStudio 64-bit VM would not duplicate the issue. However, at exit I would get a segfault, but it was in some generic GNU C code; nothing in Sequencer64 itself. I should run valgrind on it at some point.

[mxmilkiib]

64bit here, Arch Linux. I've tried with -A, -C, -J, crashes with all.

Here's a valgrind output from clicking start then pause crash. "==7761== Invalid read of size 8" occurs on the second click.

When not using valgrind, it sometimes takes until the third click (the second click of "play") for the crash, rather than two clicks. However, that sometimes depends on the theme..

Edit: I just changed theme to Raleigh, the gtk2 default, and I got different valgrind results.

Edit2: I had changed ~/.config/gtk-2.0/gtkrc-2.0. I forgot I had a ~/.gtkrc-2.0, so changed that to Raleigh, seq64 looked different (again. hmm...) and I got this instead, which looks the same as the first.

Och. @ahlstromcj; to be sure, what theme should I test with?

seq64 0.94.3-0-ga735df5f * master 2018-01-15
Build features:

Native JACK/ALSA (rtmidi) * = ON
ALSA-only MIDI support * = off
PortMIDI support * = off
Event editor * = ON
Event multimap (vs list) = off
Follow progress bar = ON
Highlight edit pattern * = ON
Highlight empty patterns = ON
JACK session * = ON
JACK support * = ON
LASH support * = off
MIDI vector (vs list) = ON
Pause support * = ON
Save time-sig/tempo = ON
Seq32 chord generator * = ON
Seq32 LFO support * = ON
Seq32 menu buttons = ON
Seq32 transpose * = ON
Solid piano-roll grid = ON
Main window scroll-bars = off
Multiple main windows * = ON
Box song selection = off
Statistics support * = off
Windows support * = off
Debug code * = ON
64-bit support enabled

[ahlstromcj]

Thanks for the information. I think something funky (hehe) is going on with Gtk's image handling. Anyway, no matter how much I pound on the play button, all I get from valgrind is one invalid read inside set_play_image(), and never a seqfault. However, since it is in a timer callback, I tweaked the image reallocation and I added a mutex lock to set_play_image().

Checkout and pull the latest from the tempo_track branch and try that out.

Also, one other trick is to edit sequencer64.usr, look for the window_redraw_rate value, and increase that value to slow down the redraw rate, which reduces the frequency of calls to timer_callback().

Let me know if you get any improvement, or not. Thanks so much for the valgrind logs!

[ahlstromcj]

Actually, it just occurred to me that it is a recursive mutex, so it may be useless. Depends if Gtk spawns a new thread for each call to timer_callback(). I gotta check into that.

[ahlstromcj]

And supposedly Gtk has a global lock made automatically for the app. Fingers crossed!

[mxmilkiib]

I'm afraid it's still the same behaviour.

Edit: wait, I built the wrong branch there..

Edit2: no, I did actually built the right branch

Edit3: this is from double clicking on a pattern

[ahlstromcj]

That one is even weirder, since there's no timer callback at all. How can simply changing an image on a button cause a segfault, but only on some systems???!

Anyway, I coded a couple workarounds to get you going while we try to figure this crap out.

First, exit seq64. Second, back up your copy of $HOME/sequencer64/sequencer64.usr. Third, open the sequencer64.usr file in a text editor and go to the bottom of that file. Just above the "End of" line, paste in the following:

[user-work-arounds]

1 # work_around_play_image

1 # work_around_transpose_image

The first option will cause the play button to not change its image. When I used that option, I get no "Invalid reads" from valgrind.

The second option avoids changing the transpose button image in the pattern editor.

Let me know if that works around the issues so that you can use seq64, or else not, or if there are any other gotchas. In the mean time, I will try to dig deeper. Good luck!! Weird stuff!!

[ahlstromcj]

OKAY!!!! I got a clean valgrind run here after finding I had mismanaged some of the button-image changes.

Not yet official until you guys give me the "all clear". Check out the latest code from "tempo_track", build, and test your scenarios.

If you did the [user-work-arounds] noted above, just change the 1's to 0's and run through the actions that caused your segfaults. If not, just build, run, and test.

Thanks! And I apologize for loading the time-bomb into Sequencer64! Mea culpa! Demasiado!

[mxmilkiib]

Strange, it was occurring when I certainly had the ugly Raleigh gtk2 theme selected (after, aside from having had two configs, also remembering to update xsettingsd).

But the problem does now appear to be resolved! Thanks! :)

[axelman0]

It's alive!!! Ty ahlstromcj for you attention to this issue!