fetch wrong key state
Closed this issue · 19 comments
Hi @trebmuh
Related to the issue you've reported on IRC, I checked your log http://paste.alacon.org/46731 and it looks to me as if Mamba indicate you've pressed 'ctrl +q' which quit the application.
It seems as if Mamba indicate the wrong key state and sym.
To ensure the correct keysym will be fetched, I use now the identifiers from keysymdef.h for the accel keys as well.
Also I've add a printout when 'ctrl +q' will be indicated.
Please try the latest commit and let me know if it works correct now, or at least, when not, if you get a printout when the application exits unexpected.
Hi @brummer10
Build from GIT master 3474449 with CXXFLAGS += -Wall and make debug, it still --c-r-a-s-h-e-s-- quits unexpectedly. Full log.
This is really strange. I couldn't see a key press event in the log, normally there should be a line like
Widget_t KeyPress 37
Widget_t KeyRelease 37
when you press a key. All we could do now is remove support for accelerated keys to try if that work (and as it have work before it should). Still the issue is not that it crash, but it quit unexpected. It should quit, for example when you press ctrl +c or ctrl +q.
I'll send a note here when I've removed the acceleration for the next test.
Thanks so far
hermann
OK, I'll wait for your note then.
So there is now a new branch no-accelerators
please pull and checkout no-accelerators
normal build: quits unexpectedly
build with CXXFLAGS += -Wall: quits unexpectedly
debug build quits unexpectedly
debug build with CXXFLAGS += -Wall: quits unexpectedly
You do a
make clean
git pull
git checkout no-accelerators
make
so now I'm completely puzzled.
What is with the last release? Did that work as expected?
I did:
git clone https://github.com/brummer10/Mamba.git --recursive
cd Mamba
git checkout no-accelerators
(so I'm building from f38b0a3 branch "no-accelerator")
Then, modify (or not) the Makefile with CXXFLAGS += -Wall
then make or make debug
I did 4 different builds to test every possible combination.
They all fails (quits unexpectedly) as reported on my previous message.
The biggest issue is that I cant reproduce this behaviour here. So, to solve it we need to find out which commit introduce this issue. I guess a good starting point will be 0dcecfb This is the last commit before I introduce support for libsmf
so you may try a
make clean
git checkout 0dcecfb9b
make
on your last checkout, and try if that work reliable.
If so, please try
make clean
git checkout e39e8f9b
make
this will be then with support to load/save Midi files.
if that still work please try the next commit as long as it start behave unexpected.
As I said, I'm not able to reproduce the failure. I tried hard, but nothing. I've installed mate desktop, I set my locale to "fr_FR.utf8", but it still work as expected. So when one of you been able to find a commit which works while the next commit didn't work any more, we may be able to indicate the issue.
From the log it is clear that the main loop receive a 'quit' signal, and the only 'quit' signals which I don't print out in debug mode been the ones from the desktop manager, and the shot down message from jack. Still, when jack shot down a application, there would be a message printout from jack anyway.
I tried to move to the second commit (there is no makefile in the first one), but the problem is still there.
Note that I have this problem under Librazik3 (debian buster base), and not under Ubuntu 18.04+KxStudio Packages.
Under Librazik3, the problem appears with Mate, Kde Plasma, and Kde Plasma Wayland too.
@brummer10 : something very strange/weird that I didn't mention yet, but it sounds it's a good time now.
At one time, I did a .deb package and mamba was working (ie: not quitting unexpectedly). Then, I repackaged with a CXXFLAGS modification and in debug mode, and then mamba wasn't working anymore... so I was like "never mind, I'll just take out the CXXFLAGS modification and the debug mode and will rebuild a package and that'll work". Which is what I did, except that mamba wasn't working anymore... I was very puzzled, specifically because since I was deb-packaging it, the chroot environment wasn't different at all. So it seemed too much like magic to me and I figured I'd talk about it when I found a reproducible way... which I couldn't find.
I don't know what to think about all of this. I hope it'll ring a bell for you.
@trebmuh there is only one thing which may be related, that's the config files of Mamba. It's ~/.config/Mamba.conf and ~/.config/Mamba.confvev. But still it seems unlikely that they could lead to such a result. Still, all other cases been even more unlikely.
I use debian/sid which isn't different in any library's Mamba use compared to buster.
Next step will be that I do a test install of Librazik3, do you've a image for me to test it out?
I mean it's much more efficient when I could reproduce the issue and nail it down, as if you spent more time on it.
Okay, I have a test install from debian buster now and could reproduce the issue. Very wired but now I could investigate.
OK. Let me know if I can help you in any way.
So I've found the source of the issue. I've pushed a fix to the repository.
Please let me know if that fixed the issue for you as well.
Confirmed.
Awesome!
Thanks for confirming the fix. So I'll close the issue now and push out a new release tomorrow.
regards
hermann