AntiMicroX / antimicrox

Graphical program used to map keyboard buttons and mouse controls to a gamepad. Useful for playing games with no gamepad support.
GNU General Public License v3.0
2.44k stars 141 forks source link

Random Crashes during longer sessions #133

Closed klopstock-dviz closed 2 years ago

klopstock-dviz commented 3 years ago

Describe the bug App crashes repeatadly, sometimes 2 or 3 times per day; other times 2 or 3 times per hour

To Reproduce Nothing particular

Screenshots Logs on the terminal chougar@pc-argon:~$ antimicrox free(): invalid pointer Abandon (core dumped) chougar@pc-argon:~$ antimicrox free(): invalid pointer Abandon (core dumped) chougar@pc-argon:~$ antimicrox Erreur de segmentation (core dumped) chougar@pc-argon:~$ antimicrox free(): invalid pointer Abandon (core dumped)

Configuration Version of antimicrox: 3.1.3 Used package: github sources System version: LMDE 3

Additional context I share my profile, perhaps it is the source of the problem: total war.gamecontroller.amgp.tar.gz

additional info I use an xbox 360 controller The crashes happen only when I use the controller I am not sure if it is systematic but i have noticed the crashes happen when i fully push the directionnal stick

zpangwin commented 3 years ago

I am experiencing similar crashes. Also using v3.1.3 but running it on Fedora 33 (Cinnamon spin); installed via dnf. I have LMDE-4 on another pc so I might try there later and report back for that as well.

I am using it with a wireless xbox 360 controller. At first I thought it was just crashing when the controller did an auto-shutoff (bc wireless)... and for that specific case I didn't care so much as it only usually happens when I get a phone call or get distracted and step afk (mmm food, etc)... i can easily restart it when i get back. However, while playing Beyond Good and Evil (GOG version via Lutris wrapper), I have been noticing it crash while in-game without the controller shutoff happening; one second i'm moving around, then all of a sudden my character is dead in the water (one time quite literally).

The profile I'm using was created in antimicrox (it is not an old antimicro import if that matters) and source is available here. I've had maybe 3-4 crashes out-of-game over the last couple nights while creating profiles for several games and at least 2 crashes in-game this evening.

Didn't see any logs under ~/.config/antimicrox but happy to provide additional info; just ask.


Edit (2020/Dec/30): got another crash, this time I had launched it from the terminal which displayed the following after the crash

$ antimicrox
malloc(): unaligned tcache chunk detected
Segmentation fault (core dumped)

Edit 2 (2020/Dec/30): Had another crash and decided to try to rule out any issues with my system, controller, etc. So I went ahead and installed the legacy antimicro 2.2.3 from an opensuse rpm here using sudo dnf install rpm antimicro-2.23-lp152.1.11.x86_64.rpm. After this, I loaded up the same profile. I did have to re-map the RMB/LMB for xbox R/L triggers but aside from that no crashes in the last hour or so. Off to bed; will test more later.


gombosg commented 3 years ago

Looks like some memory management issue... @pktiuk do you know how to get better debug logs for these crashes?

zpangwin commented 3 years ago

So was reading up a bit on where coredump files get located. What I found here was saying that if you ran sysctl kernel.core_pattern or cat /proc/sys/kernel/core_pattern it will tell you either the location or if it begins with a pipe, then the command used to process coredumps. On some systems/setups, the ulimit may default to 0 and prevent coredumps. On my system, I get:

$ ulimit -c
unlimited

$ sysctl kernel.core_pattern
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h

And the man page for systemd-coredump indicates these are stored at /var/lib/systemd/coredump.

Sure enough:

$ l /var/lib/systemd/coredump
total 49M
-rw-r-----+ 1 root root 6.2M Dec 28 20:28 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.18740.1609205325000000.zst
-rw-r-----+ 1 root root 6.1M Dec 28 22:51 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.27053.1609213869000000.zst
-rw-r-----+ 1 root root 5.6M Dec 29 00:53 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.48163.1609221221000000.zst
-rw-r-----+ 1 root root 4.1M Dec 30 23:03 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.654497.1609387438000000.zst
-rw-r-----+ 1 root root 4.0M Dec 29 01:52 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.67208.1609224747000000.zst
-rw-r-----+ 1 root root 4.5M Dec 30 23:34 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.802740.1609389261000000.zst
-rw-r-----+ 1 root root 4.4M Dec 30 23:54 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.803684.1609390466000000.zst
-rw-r-----+ 1 root root 5.3M Dec 31 00:09 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.804114.1609391362000000.zst
-rw-r-----+ 1 root root 4.1M Dec 31 00:44 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.810708.1609393495000000.zst
-rw-r-----+ 1 root root 4.4M Dec 31 00:53 core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.814352.1609394001000000.zst

Tried copying one to my desktop and changing ownership but apparently wasn't able to read it...

$ sudo cp -a -t ~/Desktop /var/lib/systemd/coredump/core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.810708.1609393495000000.zst
$ mv core.antimicrox.1000.912ec425e95f4cda8df65f69288c28cf.810708.1609393495000000.zst core.antimicrox.zst
$ sudo dnf debuginfo-install antimicrox-3.1.3-1.fc33.x86_64
$ gdb $(which antimicrox) ./core.antimicrox.zst
GNU gdb (GDB) Fedora 10.1-2.fc33
... # omitting licensing and usage output for brevity
"/home/myfedora/Desktop/./core.antimicrox.zst" is not a core dump: file format not recognized
(gdb)

Apparently zst files are some lzma compressed files.. not raw coredumps. using coredumpctl gdb $(which antimicrox) ./core.antimicrox.zst works fine though.

Excerpt from stacktrace (ignoring external libs and focusing on antimicro files):

$ coredumpctl gdb $(which antimicrox) ./core.antimicrox.zst

   Message: Process 814352 (antimicrox) of user 1000 dumped core.

            Stack trace of thread 814368:
            ... external libs/binaries
            #8  0x00007f69fa8f5dc7 _ZN7QString15fromUtf8_helperEPKci (libQt5Core.so.5 + 0x16ddc7)
            #9  0x00007f69fbe0c58d _ZN14GameController16getNumberRawAxesEv (libantilib.so.1 + 0x14458d)
            #10 0x00007f69fbe3490f _ZN25InputDeviceBitArrayStatusC2EP11InputDevicebP7QObject (libantilib.so.1 + 0x16c90f)
            #11 0x00007f69fbe2b9b1 _ZN11InputDaemon26createOrGrabBitStatusEntryEP5QHashIP11InputDeviceP25InputDeviceBitArrayStatusES2_b (libantilib.so.1 + 0x1639b1)
            #12 0x00007f69fbe2bc03 _ZN11InputDaemon14firstInputPassEP6QQueueI9SDL_EventE (libantilib.so.1 + 0x163c03)
            #13 0x00007f69fbe2cac6 _ZN11InputDaemon3runEv (libantilib.so.1 + 0x164ac6)
            #14 0x00007f69faa31d1e _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2a9d1e)
            ... external libs/binaries

            Stack trace of thread 814352:
            ... external libs/binaries
            #5  0x00007f69faa101b4 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2881b4)
            #6  0x0000561a6de45f88 main (antimicrox + 0xcf88)
            #7  0x00007f69fa3d81e2 __libc_start_main (libc.so.6 + 0x281e2)
            #8  0x0000561a6de47aae _start (antimicrox + 0xeaae)
zpangwin commented 3 years ago

Forgot to attach actual coredump yday and wiped out the old ones... so here's a fresh one. This happened after rebooting the pc, and using steam version of game instead of gog version.

Also some basic system info in case it is helpful:

$ inxi
CPU: 8-Core AMD FX-9590 (-MCP-) speed/min/max: 1406/1400/4700 MHz Kernel: 5.9.14-200.fc33.x86_64 x86_64 Up: 3h 20m 
Mem: 4051.4/32127.1 MiB (12.6%) Storage: 10.10 TiB (57.6% used) Procs: 322 Shell: Bash inxi: 3.1.08 

Gitub apparently doesn't like zst files so I put it in a tar.gz

antimicrox-coredumps.tar.gz

pktiuk commented 3 years ago

Thank you for these reports, I will investigate them later, currently I am not able to do it due to lack of time.

Looks like some memory management issue... @pktiuk do you know how to get better debug logs for these crashes?

For now these coredumps are a good place to start.
It would be good to also provide some logs from AntiMicroX itself (--log-level debug), but saving them may be a bit problematic, because of: https://github.com/AntiMicroX/antimicrox/issues/78 and mess in logging system in general.
Temporal solution for saving logs: https://github.com/AntiMicroX/antimicrox/issues/78#issuecomment-753457227

zpangwin commented 3 years ago

I need to find some time to test more thoroughly but my initial retest tonight for about 30-40 minutes using

$ antimicrox --log-level debug > ~/Desktop/antimicrox.$(date +'%Y%m%d%H%M%S').log

didn't have any issues with it crashing. App version doesn't appear to have changed...

# confirming installed version
$ dnf list installed antimicrox
Installed Packages
antimicrox.x86_64                     3.1.3-1.fc33                      @updates

# confirming there were no updates between my other post and now
$ sudo dnf history list antimicrox
ID     | Command line                                                                                | Date and time    | Action(s)      | Altered
--------------------------------------------------------------------------------------------------------------------------------------------------
    54 | update                                                                                      | 2020-11-27 09:08 | I, U           |  366 E<
    16 | install -y antimicrox kdiff3 krename meld                                                   | 2020-11-09 23:51 | Install        |    9 >

Will try to find some more time to test further and see if I can't determine if it was a fluke, some dependency on my system that got updated, if the --log-level debug has some impact on stability, or it was something to do with my game setup.

zpangwin commented 3 years ago

Update: was able to do some more testing today. This time I had antimicrox up for a little over 2 hours and again did not see any crashes. For this session, I was still on the same system (fedora 33 cinnamon) with the same wireless xbox360 controller but had tried a different game / new antimicrox profile and I did not use the --log-level debug option as I wanted to establish if I could recreate the original scenario of frequent crashes without it. I was unable to recreate during this session which leads me to think that maybe there was a dependency update or some other condition(s) I have not been able to identify which are required for the crashes to occur under.

@klopstock-dviz, are you still able to create the crashes under LMDE? If so, would you mind capturing the --log-level debug output? I appear to no longer be able to recreate the crashes (for the moment at least).

klopstock-dviz commented 3 years ago

Yes I am still experiencing the crashes, 2 or 3 for 7 hours of usage, only in with a desktop usage (i dont use the app for gaming) I have tried to capture the output with this setting: https://github.com/AntiMicroX/antimicrox/issues/78#issuecomment-753457227 The app is not usable, it crashes after 2 or 3 minutes, and the output is empty

pktiuk commented 3 years ago

@klopstock-dviz

and the output is empty

Sorry, I made a mistake in that example, there should be:

 Exec=antimicrox --log-level debug 2> /tmp/antimicrox.log

With 2> instead od >

klopstock-dviz commented 3 years ago

The param above solved the systematic crashes I had another 'regular' crash this morning I can't find the output on the tmp folder This is what I can see: image

My params: image

pktiuk commented 3 years ago

@klopstock-dviz
you have added needed flags, but in wrong place, with change in this place you will create these logs only if you would open antimicrox using right mouse button and clicking on "open in system tray only"

Full desktop entry creating logs

[Desktop Entry]
Name=AntiMicroX
Comment=Use a gamepad to control a variety of programs
Name[sr]=Анти-микро
Comment[sr]=Користите џојстик или играћу тастатуру за управљање различитим програмима
Name[fr]=AntiMicroX
Comment[fr]=Utilisez une manette de jeu pour commander un logiciel
Name[de]=AntiMicroX
Comment[de]=Nutze das Gamepad um Programme/Spiele zu steuern
Comment[uk]=Використовуйте ігровий маніпулятор для керування програмами
Exec=antimicrox --log-level debug 2> /tmp/antimicrox.log
Icon=io.github.antimicrox.antimicrox
StartupNotify=true
Terminal=false
Type=Application
Categories=Qt;Utility;
MimeType=application/x-amgp;
Keywords=game;controller;keyboard;joystick;mouse;
Actions=run-in-tray;

[Desktop Action run-in-tray]
Name=Open in system tray only
Exec=antimicrox --tray --log-level debug 2> /tmp/antimicrox.log 
klopstock-dviz commented 3 years ago

OK I pasted the config above Give you the logs when produced

klopstock-dviz commented 3 years ago

The app crashed 4 times today I don't have any output: image

This is the config i have used: image

When i let the sub menu "load profile" open, it seems the app don't crash anymore

pktiuk commented 3 years ago

If saving logs doesn't work even when this config is applied then don't bother to collect them anymore.

When i let the sub menu "load profile" open, it seems the app don't crash anymore

This is very interesting.
I will deeper investigate it when I will find some time for this.

4n0nct commented 3 years ago

It still crash like crazy, making it totally unusable, core dumped, core dumped...For the last version, and the version before that, and the version before that.

pktiuk commented 3 years ago

I know,
this issue was probably introduced during the fight with memory leaks and I think it caused some problems with it.

I am investigating new ways of removing these crashes without causing new leaks, but I am focusing on the related issue (https://github.com/AntiMicroX/antimicrox/issues/76 ), because that one is easier to reproduce on my setup.

zpangwin commented 3 years ago

It still crash like crazy, making it totally unusable, core dumped, core dumped...For the last version, and the version before that, and the version before that.

If you need a workaround, then looking at my previous comments in this ticket from back in Jan, v3.1.3 had been working as of Jan 10 for me on Fedora 33 Cinnamon. Prior to that, I had also downloaded an rpm version of the old / original antimicro-2.23 to get me through when I was experiencing issues. If you are not on an rpm-based distro, probably the only thing useful is the version number. Good luck! Hopefully that helps until a fix is created.

4n0nct commented 3 years ago

Thank you I will look at it and try to downgrade

pktiuk commented 3 years ago

I have commited come fixes tackling problems with deallocating memory.

I have created a test release on my fork https://github.com/pktiuk/antimicrox/releases/tag/3.1.6-crash-fixes

Would you like to test it?

klopstock-dviz commented 3 years ago

Hi Pawel Thank you I am testing the app image version

pktiuk commented 3 years ago

@klopstock-dviz

Please let me know how it works when you will finish playing.

noisecode3 commented 3 years ago

I have the same problem on Manjaro with aur git. I gonna trying with gdb now. I only got antimicrox  ✔ zsh: segmentation fault (core dumped) antimicrox

pktiuk commented 3 years ago

I have the same problem on Manjaro with aur git.

I don't use arch-based systems IDK what is in aur git. Please just specify your version.
For test purposes, you could test how it works with test build I mentioned above (https://github.com/AntiMicroX/antimicrox/issues/133#issuecomment-910585695)
Please let me know whether it helped in any way.

noisecode3 commented 3 years ago

its this it just means I have the latest git on Manjaro. Okej nice I try that fork

pktiuk commented 3 years ago

According to link you mentioned, package antimicrox-git is not maintained anymore. It was not updated since a long time.

noisecode3 commented 3 years ago

Arch is kind of messy that way, they don't update those, trust me I have b88fc01 commit.

BanditSan commented 3 years ago

According to link you mentioned, package antimicrox-git is not maintained anymore. It was not updated since a long time.

@pktiuk Technically you don't really need to update aur build script which are tagged as -git. Unless something major changes in build script or dependencies properly written PKGBUILD will clone latest commit from git and compile it. Current version of antimicrox-git does exactly that

noisecode3 commented 3 years ago

still crashes for me with fork. but longer, I think :)

pktiuk commented 3 years ago

I think I have found the root cause of this issue.
Could you test another build for me?
https://github.com/pktiuk/antimicrox/releases/tag/3.1.6-crash-fixesv2

noisecode3 commented 3 years ago

sure I test this tomorrow, I have a lot physics and chemistry homework. I need play for several hours and maybe for some days to really know. I love this project. I play tomb raider 3 with my ps4. thank you thank you!!

noisecode3 commented 3 years ago
Thread 1 "antimicrox" received signal SIGSEGV, Segmentation fault.
0x00007ffff6401576 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff6401576 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
#1  0x00007ffff6934e5c in QString::append(QString const&) ()  from /usr/lib/libQt5Core.so.5
#2  0x00007ffff6949c73 in QtPrivate::QStringList_join(QStringList const*, QChar const*, int) () from /usr/lib/libQt5Core.so.5
#3  0x00005555555be7c3 in QListSpecialMethods<QString>::join(QString const&) const ()
#4  0x0000555555699db8 in JoyControlStickButton::getCalculatedActiveZoneSummary() ()
#5  0x00005555556ade73 in JoyControlStickButtonPushButton::generateLabel() ()
#6  0x000055555563a2d4 in FlashButtonWidget::refreshLabel() ()
#7  0x0000555555630abd in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (FlashButtonWidget::*)()>::call(void (FlashButtonWidget::*)(), FlashButtonWidget*, void**) ()
#8  0x000055555563098a in void QtPrivate::FunctionPointer<void (FlashButtonWidget::*)()>::call<QtPrivate::List<>, void>(void (FlashButtonWidget::*)(), FlashButtonWidget*, void**) ()
#9  0x00005555556308b0 in QtPrivate::QSlotObject<void (FlashButtonWidget::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ()
#10 0x00007ffff6ad2047 in QObject::event(QEvent*) ()
   from /usr/lib/libQt5Core.so.5
--Type <RET> for more, q to quit, c to continue without paging--
#11 0x00007ffff7a2dff6 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#12 0x00007ffff6aa41aa in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#13 0x00007ffff6aa7359 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5
#14 0x00007ffff6afe4b8 in ?? () from /usr/lib/libQt5Core.so.5
#15 0x00007ffff543910c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#16 0x00007ffff548cba9 in ?? () from /usr/lib/libglib-2.0.so.0
#17 0x00007ffff5436871 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#18 0x00007ffff6afdaca in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#19 0x00007ffff6aa2a5b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#20 0x00007ffff6aab248 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#21 0x0000555555599d14 in main ()

extra info All i did was minimize the window in gnome3

pktiuk commented 3 years ago

Does this crash happen often/always?
According to logs you have provided, this doesn't seem to be related with other crashes in this issue.

noisecode3 commented 3 years ago

only when minimizing, I played most of the day lol over 12 hours seem to work. It happens randomly after some time when minimizing

noisecode3 commented 3 years ago
Thread 1 "antimicrox" received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000055555572913a in MainWindow::showBatteryLevel(SDL_JoystickPowerLevel, QString, QString, InputDevice*) ()
#2  0x000055555572a15b in MainWindow::checkEachTenMinutesBattery(QMap<int, InputDevice*>*) ()
#3  0x000055555571ddc3 in MainWindow::MainWindow(QMap<int, InputDevice*>*, CommandLineUtility*, AntiMicroSettings*, bool, QWidget*)::{lambda()#5}::operator()() const ()
#4  0x000055555572b558 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, MainWindow::MainWindow(QMap<int, InputDevice*>*, CommandLineUtility*, AntiMicroSettings*, bool, QWidget*)::{lambda()#5}>::call(MainWindow::MainWindow(QMap<int, InputDevice*>*, CommandLineUtility*, AntiMicroSettings*, bool, QWidget*)::{lambda()#5}&, void**) ()
#5  0x000055555572b326 in void QtPrivate::Functor<MainWindow::MainWindow(QMap<int, InputDevice*>*, CommandLineUtility*, AntiMicroSettings*, bool, QWidget*)::{lambda()#5}, 0>::call<QtPrivate::List<>, void>(MainWindow::MainWindow(QMap<int, InputDevice*>*, CommandLineUtility*, AntiMicroSettings*, bool, QWidget*)::{lambda()#5}&, void*, void**) ()
#6  0x000055555572b173 in QtPrivate::QFunctorSlotObject<MainWindow::MainWindow(QMap<int, InputDevice*>*, CommandLineUtility*, AntiMicroSettings*, bool, QWidget*)::{lambda()#5}, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) ()
#7  0x00007ffff6adb8b5 in ?? () from /usr/lib/libQt5Core.so.5
--Type <RET> for more, q to quit, c to continue without paging--c
#8  0x00007ffff6adfa2f in QTimer::timeout(QTimer::QPrivateSignal) () from /usr/lib/libQt5Core.so.5
#9  0x00007ffff6ad1fdf in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#10 0x00007ffff7a2dff6 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#11 0x00007ffff6aa41aa in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#12 0x00007ffff6afcdad in QTimerInfoList::activateTimers() () from /usr/lib/libQt5Core.so.5
#13 0x00007ffff6afd732 in ?? () from /usr/lib/libQt5Core.so.5
#14 0x00007ffff543910c in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#15 0x00007ffff548cba9 in ?? () from /usr/lib/libglib-2.0.so.0
#16 0x00007ffff5436871 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#17 0x00007ffff6afdaca in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#18 0x00007ffff6aa2a5b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#19 0x00007ffff6aab248 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#20 0x0000555555599d14 in main ()

Changing from Bluetooth to usb did crash also, there is no crashing in the game anymore for me with 3.1.6-crash-fixesv2

pktiuk commented 3 years ago

That is all I need for now, that experimental fix needs some additional refinement from me.
Other fixes are already a part of new release 3.1.7

noisecode3 commented 3 years ago

I have been playing a lot. Minimized window. There is no crashes for me with 3.1.7 good job.

pktiuk commented 3 years ago

Thanks for your assistance @noisecode3

I am closing this issue for now.
If anyone will have any crashes, I will reopen this.

TheFeelTrain commented 2 years ago

I am still getting the same crash as @zpangwin on version 3.1.7. It happens in pretty random intervals, anywhere from a few hours to a few days while using a controller as a mouse.

malloc(): unaligned tcache chunk detected
fish: Job 1, 'antimicrox' terminated by signal SIGABRT (Abort)
TheFeelTrain commented 2 years ago

Any ideas on how to go about debugging this? I get nothing in the logs when it crashes. As far as I can tell the malloc(): unaligned tcache chunk detected indicates it's an error involving buffers. It's crashing on me at least once a day so I'd like to figure it out but I know nothing of C++. Is there some kind of stack tracing I can enable to try to nail it down?

pktiuk commented 2 years ago

Could you tell me about your config? (system, used gamepad)
You can collect some debug logs with debug build available here.
Collecting logs instruction: https://github.com/AntiMicroX/antimicrox/wiki/Collecting-Logs

TheFeelTrain commented 2 years ago

Xbox One controller on Arch Linux using the antimicrox-git package from the AUR. Previously I was using the 3.1.7 package from chaotic-aur but I switched to see if that was the issue (it wasn't)

Although is my bad for not checking the commits before commenting, I noticed you literally just added a stack trace on SIGABRT yesterday so I have rebuilt from the latest commit and will wait for it to crash again.

Also I have logs set to verbose because debug logs every single stick movement which is a lot when using it as a mouse. I didn't want to wear out my SSD. I also figured it would output errors regardless of level although I guess that's not the case. I'll see if the stack trace gives anything interesting first.

EDIT: Oh and here is the controller config in case you wanted to look at it Jerry.gamecontroller.zip (had to zip it for GitHub to accept it)

pktiuk commented 2 years ago

Although is my bad for not checking the commits before commenting, I noticed you literally just added a stack trace on SIGABRT yesterday so I have rebuilt from the latest commit and will wait for it to crash again.

That's true, but only debug build with some debug flags will properly print stack trace. That's why I recommended special debug AppImage build (it won't mess with your current instance).

Also I have logs set to verbose because debug logs every single stick movement which is a lot when using it as a mouse. I didn't want to wear out my SSD.

I think in this case Verbose should be just fine.

I also figured it would output errors regardless of level although

Only a fer warnings are printed when log level is set to non. Bug issue https://github.com/AntiMicroX/antimicrox/issues/189 (these warnings are printed, because they occur before app knows log level)

TheFeelTrain commented 2 years ago

It happened pretty quick again. I just realized I think I am clearing the logs every time when I restart it. But my controller is my main input method so I kind of need it to be running to look at the logs in the first place lol. I will use M/KB next time instead.

Anyways, same error with the AppImage, seems like the stack trace isn't particularly useful or isn't working properly?

thefeeltrain@archlinux ~/Downloads> ./AntiMicroX-debug-x86_64.AppImage
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
malloc(): unaligned tcache chunk detected
terminate called after throwing an instance of 'std::runtime_error'
  what():  There is no logger instance
fish: Job 1, './AntiMicroX-debug-x86_64.AppIm…' terminated by signal SIGABRT (Abort)

I will set logs to debug and then make sure not to reopen it so they don't get reset. Seems to be happening a lot now, this is the third crash today. Usually it's not this frequent.

TheFeelTrain commented 2 years ago

Okay nevermind I remember why I didn't use log level debug. In about 3 and a half minutes my log file is at 48 MiB. It's just way too much. I will stick with verbose. antimicrox.zip

TheFeelTrain commented 2 years ago

There is nothing in the logs still, so I guess they weren't resetting. And just more of the same error. Got my 4th crash so it seems to be happening every couple of hours at this point. I think it might just be dependent on how many inputs I do. I think it tends to crash less if I watch more video since then I'm not inputting anything. Could it be related to the debug log growing rapidly? I'm wondering if once it reaches a certain amount of inputs, it overflows causing this tchunk error.

pktiuk commented 2 years ago

Could it be related to the debug log growing rapidly? I'm wondering if once it reaches a certain amount of inputs, it overflows causing this tchunk error.

Only debug level generates so big amount of data. Anyway I don't think size of log file could cause any crash.
If you want to avoid dealing with log files you can just collect logs from stdout. (clear log file specified in settings to print to stdout) and in case of crash paste me several last lines of logs (describing stack trace, cause of error and some previous lines for context).

noisecode3 commented 2 years ago

If you use gdb you can back trace the crash and see where is happens. Memory was not manage properly. gdb /path/to/antimicrox typ:

start or run Enter

The doc say:

"The ‘start’ command does the equivalent of setting a temporary breakpoint at the beginning of the main procedure and then invoking the ‘run’ command.

Some programs contain an elaboration phase where some startup code is executed before the main procedure is called. This depends on the languages used to write your program. In C++, for instance, constructors for static and global objects are executed before main is called. It is therefore possible that the debugger stops before reaching the main procedure. However, the temporary breakpoint will remain to halt execution."

when it crashes you go to terminal and typ:

bt Enter

typ c Enter again or just Enter again. and again until you don't get any more text

Then paste all the output here.

gdb runs the program like in a container and its supper useful.

TheFeelTrain commented 2 years ago
Starting program: /usr/bin/antimicrox 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff2bfa640 (LWP 606246)]
[New Thread 0x7fffebecf640 (LWP 606247)]
[New Thread 0x7fffe8a33640 (LWP 606248)]
[New Thread 0x7fffda370640 (LWP 606249)]
[New Thread 0x7fffd9b6f640 (LWP 606250)]
[New Thread 0x7fffd936e640 (LWP 606251)]
[New Thread 0x7fffd8b6d640 (LWP 606252)]
[New Thread 0x7fffcbfff640 (LWP 606253)]
[New Thread 0x7fffcb7fe640 (LWP 606254)]
[New Thread 0x7fffcaffd640 (LWP 606255)]
[New Thread 0x7fffca7fc640 (LWP 606256)]
[New Thread 0x7fffc9ffb640 (LWP 606257)]
[New Thread 0x7fffc97fa640 (LWP 606258)]
[New Thread 0x7fffc8ff9640 (LWP 606259)]
[New Thread 0x7fffa7fff640 (LWP 606260)]
[New Thread 0x7fffa77fe640 (LWP 606261)]
[New Thread 0x7fffa6ffd640 (LWP 606262)]
[New Thread 0x7fffa67fc640 (LWP 606263)]
[New Thread 0x7fffa5ffb640 (LWP 606264)]
[New Thread 0x7fffa57fa640 (LWP 606265)]
[New Thread 0x7fffa4ff9640 (LWP 606266)]
[Thread 0x7fffa67fc640 (LWP 606263) exited]
[Thread 0x7fffa6ffd640 (LWP 606262) exited]
[Thread 0x7fffc97fa640 (LWP 606258) exited]
[Thread 0x7fffcaffd640 (LWP 606255) exited]
[Thread 0x7fffcbfff640 (LWP 606253) exited]
[Thread 0x7fffc8ff9640 (LWP 606259) exited]
[Thread 0x7fffd9b6f640 (LWP 606250) exited]
[Thread 0x7fffd936e640 (LWP 606251) exited]
[Thread 0x7fffc9ffb640 (LWP 606257) exited]
[Thread 0x7fffa5ffb640 (LWP 606264) exited]
[Thread 0x7fffcb7fe640 (LWP 606254) exited]
[Thread 0x7fffa77fe640 (LWP 606261) exited]
[Thread 0x7fffca7fc640 (LWP 606256) exited]
[Thread 0x7fffda370640 (LWP 606249) exited]
[Thread 0x7fffa7fff640 (LWP 606260) exited]
[Thread 0x7fffd8b6d640 (LWP 606252) exited]

Thread 1 "antimicrox" received signal SIGSEGV, Segmentation fault.
0x00007ffff63e7576 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff63e7576 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
#1  0x00007ffff6917de8 in QString::append(QString const&) () from /usr/lib/libQt5Core.so.5
#2  0x00007ffff692c4c3 in QtPrivate::QStringList_join(QStringList const*, QChar const*, int) ()
   from /usr/lib/libQt5Core.so.5
#3  0x00005555556dcc9f in ?? ()
#4  0x00005555556ed59b in ?? ()
#5  0x000055555563e662 in ?? ()
#6  0x00007ffff6aad54f in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5
#7  0x00007ffff7a1ad62 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQt5Widgets.so.5
#8  0x00007ffff6a803fa in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5
#9  0x00007ffff6a834f9 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) ()
   from /usr/lib/libQt5Core.so.5
#10 0x00007ffff6ad99f4 in ?? () from /usr/lib/libQt5Core.so.5
#11 0x00007ffff543a4dc in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0x00007ffff548e749 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x00007ffff5437bc1 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#14 0x00007ffff6ad9026 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
   from /usr/lib/libQt5Core.so.5
#15 0x00007ffff6a7ed6c in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQt5Core.so.5
#16 0x00007ffff6a872d4 in QCoreApplication::exec() () from /usr/lib/libQt5Core.so.5
#17 0x00005555555ad9fd in ?? ()
#18 0x00007ffff62abb25 in __libc_start_main () from /usr/lib/libc.so.6
#19 0x00005555555b662e in ?? ()
(gdb) c
Continuing.
malloc(): unaligned tcache chunk detected

Thread 22 "QThread" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffa4ff9640 (LWP 606266)]
0x00007ffff62c0d22 in raise () from /usr/lib/libc.so.6
(gdb) c
Continuing.
malloc(): unaligned tcache chunk detected

Thread 22 "QThread" received signal SIGABRT, Aborted.
0x00007ffff62c0d22 in raise () from /usr/lib/libc.so.6
(gdb) c
Continuing.
malloc(): unaligned tcache chunk detected

Thread 22 "QThread" received signal SIGABRT, Aborted.
0x00007ffff62c0d22 in raise () from /usr/lib/libc.so.6
(gdb) c
Continuing.
malloc(): unaligned tcache chunk detected
[Thread 0x7fffe8a33640 (LWP 606248) exited]

Thread 22 "QThread" received signal SIGABRT, Aborted.
0x00007ffff62c0d22 in raise () from /usr/lib/libc.so.6
(gdb) c
Continuing.
malloc(): unaligned tcache chunk detected

Thread 1 "antimicrox" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff32c6840 (LWP 606239)]
0x00007ffff63e7576 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
(gdb) c
Continuing.
Couldn't get registers: No such process.
Couldn't get registers: No such process.
(gdb) [Thread 0x7fffa4ff9640 (LWP 606266) exited]
[Thread 0x7fffa57fa640 (LWP 606265) exited]
[Thread 0x7fffebecf640 (LWP 606247) exited]
[Thread 0x7ffff2bfa640 (LWP 606246) exited]

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
noisecode3 commented 2 years ago

QtPrivate::QStringList_join() isn't that like a supper old qt 4 thing? https://doc.qt.io/qt-5/qstringlist.html could it be that those are mixed with old methods and there's like a conflict in the memory, I dont know.

noisecode3 commented 2 years ago

That is tricky it happens in the systems Qt5Core lib. It is a problem for me with selecting mouse input for right joy stick. For me it freezes the gui, there is something there with the mouse input. ❗WARN QMetaMethod::invoke: Dead lock detected in BlockingQueuedConnection: Receiver is JoyControlStickEditDialogHelper(0x555556664008)

Do you also get this or is it different?

https://woboq.com/blog/how-qt-signals-slots-work-part3-queuedconnection.html I found some information, I want to jump down the rabbit hole but I don't have the time right now. Wish I could help more.