Crashing when image-info is used

KodyVB commented

2022-11-30 19:06:24 +00:00

I'm using nsxiv 30-2 from the AUR, and for the past few months I've been having the issue of nsxiv crashing under normal use. I experienced the same issue with an older version I was using which I compiled myself, too. The error message looks like:

XIO:  fatal IO error 10 (No child processes) on X server ":1"
      after 20577 requests (20450 known processed) with 0 events remaining.

Where the number of requests and known processed is different each time. I thought this was a Wayland problem since I first noticed this happen after I switched to Wayland, but after I logged out and logged back into an X11 session, I got the same issue (except the X server was ":0").

I'd open multiple pictures via nsxiv . or nsxiv -r ., and be switching between images with n/p when nsxiv would crash with the above error. It doesn't happen on a specific image. I could have just a few images open, and it will crash after I scroll through just a few of them. Then I can reopen the images with the same command and either it won't crash or it'll crash elsewhere. I can also open thousands of images and hold n or p for a long time before the crash happens (which is how I got the above error specifically).

While trying to pinpoint the issue, I removed my image-info file, which is provided. I have yet to experience a crash with the file removed. Thinking it might have been a problem with the commands I was using to get the geometry and file sizes, I replaced those with plain text (shown in image-info-secondary), and experienced a crash not long afterwards.

I'm using KDE Plasma 5.26.4, Arch 6.0.10-arch2-1, and Wayland, but I've experienced this problem for a long time on both X11 and Wayland.

I'm using nsxiv 30-2 from the AUR, and for the past few months I've been having the issue of nsxiv crashing under normal use. I experienced the same issue with an older version I was using which I compiled myself, too. The error message looks like: ``` XIO: fatal IO error 10 (No child processes) on X server ":1" after 20577 requests (20450 known processed) with 0 events remaining. ``` Where the number of requests and known processed is different each time. I thought this was a Wayland problem since I first noticed this happen after I switched to Wayland, but after I logged out and logged back into an X11 session, I got the same issue (except the X server was ":0"). I'd open multiple pictures via `nsxiv .` or `nsxiv -r .`, and be switching between images with n/p when nsxiv would crash with the above error. It doesn't happen on a specific image. I could have just a few images open, and it will crash after I scroll through just a few of them. Then I can reopen the images with the same command and either it won't crash or it'll crash elsewhere. I can also open thousands of images and hold n or p for a long time before the crash happens (which is how I got the above error specifically). While trying to pinpoint the issue, I removed my image-info file, which is provided. I have yet to experience a crash with the file removed. Thinking it might have been a problem with the commands I was using to get the geometry and file sizes, I replaced those with plain text (shown in `image-info-secondary`), and experienced a crash not long afterwards. I'm using KDE Plasma 5.26.4, Arch 6.0.10-arch2-1, and Wayland, but I've experienced this problem for a long time on both X11 and Wayland.

image-info

487 B

image-info-secondary

527 B

NRK added the

bug

label 2022-11-30 20:19:38 +00:00

NRK commented

2022-11-30 20:56:06 +00:00

Owner

Can't reproduce. Does it happen on latest master branch?

Can't reproduce. Does it happen on latest `master` branch?

NRK added the

can't reproduce

label 2022-11-30 21:38:50 +00:00

KodyVB commented

2022-11-30 21:47:59 +00:00

Poster

I cloned the repo and ran doas make install-all, put image-info back in the exec directory, and after about a minute of going through images it crashed again.

I cloned the repo and ran `doas make install-all`, put image-info back in the exec directory, and after about a minute of going through images it crashed again.

XPhyro commented

2022-11-30 22:15:54 +00:00

Owner

I was able to produce a crash with the first image-info, but with a different error code. The output was

XIO:  fatal IO error 3 (No such process) on X server ":0"
      after 4175 requests (4145 known processed) with 0 events remaining.
XIO:  fatal IO error 3 (No such process) on X server ":0"
      after 4175 requests (4145 known processed) with 0 events remaining.

with the same error twice.

The crash only happened once when I issued nsxiv -r . in a large and nested directory with 63,000 images in it and held down "next image". When I re-do the process, the crash does not happen.

I can't say for sure, but I have a feeling there might be a race condition somewhere that only happens if the drive is not warm enough.

I'm on master 3804b50656.

I assume these crashes are related, if not the same; but I'm not sure I reproduced the original issue here, so I'm not removing the "can't reproduce" label. Feel free to remove it.

I was able to produce a crash with the first `image-info`, but with a different error code. The output was ``` XIO: fatal IO error 3 (No such process) on X server ":0" after 4175 requests (4145 known processed) with 0 events remaining. XIO: fatal IO error 3 (No such process) on X server ":0" after 4175 requests (4145 known processed) with 0 events remaining. ``` with the same error twice. The crash only happened once when I issued `nsxiv -r .` in a large and nested directory with 63,000 images in it and held down "next image". When I re-do the process, the crash does not happen. I can't say for sure, but I have a feeling there might be a race condition somewhere that only happens if the drive is not warm enough. I'm on master 3804b506564. ------- I assume these crashes are related, if not the same; but I'm not sure I reproduced the original issue here, so I'm not removing the "can't reproduce" label. Feel free to remove it.

👍 1

NRK removed the

can't reproduce

label 2022-11-30 22:30:16 +00:00

NRK commented

2022-11-30 22:37:05 +00:00

Owner

geometry=$(identify -format '%wx%h' "$1[0]")

Just FYI - nsxiv passes the image w/h to image-info as 2nd and 3rd argument. So invoking an external tool isn't necessary.

```sh geometry=$(identify -format '%wx%h' "$1[0]") ``` Just FYI - nsxiv passes the image w/h to `image-info` as 2nd and 3rd argument. So invoking an external tool isn't necessary.

KodyVB commented

2022-11-30 23:05:50 +00:00

Poster

geometry=$(identify -format '%wx%h' "$1[0]")
Just FYI - nsxiv passes the image w/h to image-info as 2nd and 3rd argument. So invoking an external tool isn't necessary.

That's really nice to know. I yanked this file from I don't remember where back when I was still using sxiv. I've changed it to geometry="${2}x${3}"

> ```sh > geometry=$(identify -format '%wx%h' "$1[0]") > ``` > > Just FYI - nsxiv passes the image w/h to `image-info` as 2nd and 3rd argument. So invoking an external tool isn't necessary. That's really nice to know. I yanked this file from I don't remember where back when I was still using sxiv. I've changed it to `geometry="${2}x${3}"`

NRK commented

2023-01-09 01:46:20 +00:00

Owner

Could either of you try out the following (quick and dirty) patch and report if it fixes the issue or not? The idea here is to reduce calls to image-info in case the user has something like n pressed down.

$ curl -SsL 'https://codeberg.org/attachments/eeca6b70-c666-431d-963e-361903e572ba' | git apply

Could either of you try out the following (quick and dirty) patch and report if it fixes the issue or not? The idea here is to reduce calls to `image-info` in case the user has something like `n` pressed down. ```console $ curl -SsL 'https://codeberg.org/attachments/eeca6b70-c666-431d-963e-361903e572ba' | git apply ```

dirty.diff

1.9 KiB

KodyVB commented

2023-01-09 02:35:36 +00:00

Poster

~~Which branch should I be working in? I am in an up-to-date master branch and can't make install-all it (even without patches).~~

~~Running doas make install-all 2> err.txt to get the errors, I have the following error text file.~~

Okay I have no idea what was going on. I removed that directory, git cloned the nsxiv page from codeberg again, and it make-installed perfectly fine again.

But once I patched it in with the curl command you provided, it did crash after some images with:

XIO:  fatal IO error 10 (No child processes) on X server ":1"
      after 6186 requests (6016 known processed) with 0 events remaining.

~~Which branch should I be working in? I am in an up-to-date master branch and can't make install-all it (even without patches).~~ ~~Running `doas make install-all 2> err.txt` to get the errors, I have the following error text file.~~ Okay I have no idea what was going on. I removed that directory, git cloned the nsxiv page from codeberg again, and it make-installed perfectly fine again. But once I patched it in with the curl command you provided, it did crash after some images with: ```sh XIO: fatal IO error 10 (No child processes) on X server ":1" after 6186 requests (6016 known processed) with 0 events remaining. ```

err.txt

1.7 KiB

NRK commented

2023-01-09 03:38:13 +00:00

Owner

The compiler error was because the config.h was outdated. But looks like the patch didn't fix the issue anyways. I'm out of ideas then, and I can't reproduce it on my system so it's difficult for me to debug this.

The compiler error was because the `config.h` was outdated. But looks like the patch didn't fix the issue anyways. I'm out of ideas then, and I can't reproduce it on my system so it's difficult for me to debug this.

NRK added the

help wanted

label 2023-01-09 03:38:24 +00:00

TAAPArthur commented

2023-01-10 03:11:03 +00:00

Owner

@KodyVB

I can attempt to take over and help resolve this.

Step 1:
First off could you rebuild with minimal dependencies and see if you can reproduce this issue. Ie make clean; make CFLAGS=-g OPT_DEP_DEFAULT=0; I'd be surprised if this solves your issue, but it eliminate some code paths which may help us reason about the issue. Rebuild the following way for the remainder of these steps

Step 2:
In window.c::win_init, before anything else could you add a call to XInitThreads(). nsxiv is single threaded but I don't really trust imlib enough to make the same claim. If you can't reproduce the issue after adding this line, you can stop going through these steps.

Step 3:
In window.c::win_init, after we successfully open the X display (ie after the call to XOpenDisplay), would you able able to add in XSynchronize(dpy, 1) and reproduce under a debugger like gdb? If so would you share the stack trace. We could probably get a patch ready if we knew what function in nsxiv directly caused this error.
With XSynchronize set, the crash should happen when we make the offending X call (instead of some arbitrary amount of time later) so it should show up in the stack trace.

I can't reproduce this issue either, so I'm just describing the steps I would do to troubleshoot this. Please let me know if you need clarification on anything.

@KodyVB I can attempt to take over and help resolve this. Step 1: First off could you rebuild with minimal dependencies and see if you can reproduce this issue. Ie `make clean; make CFLAGS=-g OPT_DEP_DEFAULT=0;` I'd be surprised if this solves your issue, but it eliminate some code paths which may help us reason about the issue. Rebuild the following way for the remainder of these steps Step 2: In window.c::win_init, before anything else could you add a call to [XInitThreads()](https://www.x.org/releases/X11R7.5/doc/man/man3/XInitThreads.3.html). nsxiv is single threaded but I don't really trust imlib enough to make the same claim. If you can't reproduce the issue after adding this line, you can stop going through these steps. Step 3: In window.c::win_init, after we successfully open the X display (ie after the call to XOpenDisplay), would you able able to add in `XSynchronize(dpy, 1)` and reproduce under a debugger like gdb? If so would you share the stack trace. We could probably get a patch ready if we knew what function in nsxiv directly caused this error. With XSynchronize set, the crash should happen when we make the offending X call (instead of some arbitrary amount of time later) so it should show up in the stack trace. I can't reproduce this issue either, so I'm just describing the steps I would do to troubleshoot this. Please let me know if you need clarification on anything.

👍 1

KodyVB commented

2023-01-11 05:26:18 +00:00

Poster

Earlier this morning, I cloned the repo again to avoid having any kind of conflicts like I did previously, then ran the make clean and CFLAGS and OPT_DEP_DEFAULT options, but with those options the text at the bottom which was related to the crashing wouldn't appear.

So then I ran doas make clean and doas make clean install and for some reason, I can't reproduce the error anymore. It used to be that the error would pop up after a couple hundred pictures at most, but now I've gone through at least 16,000 pictures without issue.

The only variables that I can think of that changed were:

Running doas make clean install instead of doas make install (I'd only done uninstall before, not clean)
Maybe some unrelated patch was added to master overnight that happened to fix it
I did my usual nightly Arch updates last night and maybe one of those things affected it (I can get a list of the packages pretty easily if desired)

Earlier this morning, I cloned the repo again to avoid having any kind of conflicts like I did previously, then ran the `make clean` and `CFLAGS` and `OPT_DEP_DEFAULT` options, but with those options the text at the bottom which was related to the crashing wouldn't appear. So then I ran `doas make clean` and `doas make clean install` and for some reason, I can't reproduce the error anymore. It used to be that the error would pop up after a couple hundred pictures at most, but now I've gone through at least 16,000 pictures without issue. The only variables that I can think of that changed were: 1. Running `doas make clean install` instead of `doas make install` (I'd only done uninstall before, not clean) 2. Maybe some unrelated patch was added to master overnight that happened to fix it 3. I did my usual nightly Arch updates last night and maybe one of those things affected it (I can get a list of the packages pretty easily if desired)

eylles commented

2023-01-11 05:39:06 +00:00

Owner

hmmm i think i know what happened, the recent change to use posix_spawn() may have fixed some underlying issue with the old fork/dup/exec used for image-info, may be worth mentioning but i got a directory with around 400 png images that all average on the range of 4+ MB in size, i did experience nsxiv crashing while fast navigating that dir and i noticed it "randomly" crashing on the larger images, didn't ran enough tests to find the cause of that but i did notice that problem dissapearing since adding the usage of posix_spawn()

NRK commented

2023-01-11 08:18:19 +00:00

Owner

@KodyVB Here's an easy way to verify if the posix_spawn change was what fixed it or not, roll back to the commit right before it:

$ git checkout 76c2b81
$ make clean
$ doas make install

And then try to see if you can reproduce the crash. After that, switch back to master and try again just in case - and to do that, simply change the first command to git checkout master and the last 2 commands remain the same.

I can get a list of the packages pretty easily if desired

I'd be curious if you updated x-server, xlib or anything else X11 related.

@KodyVB Here's an easy way to verify if the `posix_spawn` change was what fixed it or not, roll back to the commit right before it: ```console $ git checkout 76c2b81 $ make clean $ doas make install ``` And then try to see if you can reproduce the crash. After that, switch back to master and try again just in case - and to do that, simply change the first command to `git checkout master` and the last 2 commands remain the same. > I can get a list of the packages pretty easily if desired I'd be curious if you updated x-server, xlib or anything else X11 related.

KodyVB commented

2023-01-11 18:25:06 +00:00

Poster

I checked out 76c2b81 and it crashed within ~700 images as usual, then checked out master again and it crashed after ~2,300 images. So maybe I just had really weird luck last night when I went through ~16,000 images without issues? Sorry if I got everyone's hopes up...

I checked out 76c2b81 and it crashed within ~700 images as usual, then checked out master again and it crashed after ~2,300 images. So maybe I just had really weird luck last night when I went through ~16,000 images without issues? Sorry if I got everyone's hopes up...

TAAPArthur commented

2023-01-12 07:46:06 +00:00

Owner

Sorry if I got everyone's hopes up..

My fears would have been up if the posix_spawn changes actually fixed your issue. I could believe it making the problem rarer since it was supposed to provide a perf improvement (especially in cases like this).

@KodyVB
Could you continue with Step 2 of #391 (comment)? (no rush) Since master may make the race harder to hit, going back to 76c2b81 sound be fine. If we can root cause the issue in any version, should be able to tell if it is truly fixed in master.

Also don't think this was the source of your issue, but would recommend always running the clean target by itself. Pretty sure you'd get undesirable behavior depending on your systems default MAKEFLAGS (like having clean race with install if -j was set). You'd probably notice if this was a problem, but thought it was worth mentioning for future reference

>Sorry if I got everyone's hopes up.. My fears would have been up if the posix_spawn changes actually fixed your issue. I could believe it making the problem rarer since it was supposed to provide a perf improvement (especially in cases like this). @KodyVB Could you continue with Step 2 of https://codeberg.org/nsxiv/nsxiv/issues/391#issuecomment-764299? (no rush) Since master may make the race harder to hit, going back to 76c2b81 sound be fine. If we can root cause the issue in any version, should be able to tell if it is truly fixed in master. Also don't think this was the source of your issue, but would recommend always running the `clean` target by itself. Pretty sure you'd get undesirable behavior depending on your systems default `MAKEFLAGS` (like having clean race with install if `-j` was set). You'd probably notice if this was a problem, but thought it was worth mentioning for future reference

KodyVB commented

2023-01-12 19:37:48 +00:00

Poster

I checked out 76c2b81, then added XInitThreads(); to window.c underneath void win_init(win_t *win) (which automatically added #include <X11/Xlib.h> to the top thanks to my IDE), at line 110, ran make clean and doas make clean install, and had the same error after ~600 images.

Then I removed those two lines, and added XSynchronize(e->dpy, 1); to the line after the if statement with the only XOpenDisplay call I could find - making it line 125 in window.c. I hadn't used gdb before, so I looked it up and saw it should be compiled with a flag, and after searching gcc's manpage I saw -ggdb was appropriate, so I added that to the end of line 20 of the Makefile. I ran make clean, make, then gdb ./nsxiv followed by run -r <directory>. After ~5,000 images, these were the last few lines in gdb:

[Detaching after fork from child process 84216]
[Detaching after fork from child process 84220]
XIO:  fatal IO error 10 (No child processes) on X server ":1"
      after 924611 requests (924611 known processed) with 0 events remaining.
[Inferior 1 (process 64113) exited with code 01]

If I should have compiled nsxiv some other way, or did something else wrong, please let me know and I'll try again.

I checked out 76c2b81, then added `XInitThreads();` to window.c underneath `void win_init(win_t *win)` (which automatically added `#include <X11/Xlib.h>` to the top thanks to my IDE), at line 110, ran `make clean` and `doas make clean install`, and had the same error after ~600 images. Then I removed those two lines, and added `XSynchronize(e->dpy, 1);` to the line after the if statement with the only `XOpenDisplay` call I could find - making it line 125 in window.c. I hadn't used gdb before, so I looked it up and saw it should be compiled with a flag, and after searching gcc's manpage I saw `-ggdb` was appropriate, so I added that to the end of line 20 of the Makefile. I ran `make clean`, `make`, then `gdb ./nsxiv` followed by `run -r <directory>`. After ~5,000 images, these were the last few lines in gdb: ``` [Detaching after fork from child process 84216] [Detaching after fork from child process 84220] XIO: fatal IO error 10 (No child processes) on X server ":1" after 924611 requests (924611 known processed) with 0 events remaining. [Inferior 1 (process 64113) exited with code 01] ``` If I should have compiled nsxiv some other way, or did something else wrong, please let me know and I'll try again.

TAAPArthur commented

2023-01-13 21:46:15 +00:00

Owner

added XInitThreads();

Unfortunate and I guess I should apologize to our imlib for suspecting them of doing something stupid to cause this problem.

If I should have compiled nsxiv some other way, or did something else wrong, please let me know and I'll try again.

You ran the command well enough. I had expected gdb to dump you shell where you could run commands like bt. But forgot that gdb would only do that by default for abnormal termination which didn't happen for this error. My bad.

Haven't given up yet though. Later tonight, I'll upload a build/patch with some extra debugging info. May also need to look at X's source to see what XIO: fatal IO error 10 (No child processes) actually means.

Also wanted to clarify that you only experience this problem when using an image-info and if that file isn't present you stop being able to reproduce this issue.

> added XInitThreads(); Unfortunate and I guess I should apologize to our imlib for suspecting them of doing something stupid to cause this problem. >If I should have compiled nsxiv some other way, or did something else wrong, please let me know and I'll try again. You ran the command well enough. I had expected gdb to dump you shell where you could run commands like `bt`. But forgot that gdb would only do that by default for abnormal termination which didn't happen for this error. My bad. Haven't given up yet though. Later tonight, I'll upload a build/patch with some extra debugging info. May also need to look at X's source to see what `XIO: fatal IO error 10 (No child processes)` actually means. Also wanted to clarify that you only experience this problem when using an `image-info` and if that file isn't present you stop being able to reproduce this issue.

TAAPArthur commented

2023-01-14 06:36:26 +00:00

Owner

So here's a branch to tryout: https://codeberg.org/TAAPArthur/nsxiv/src/branch/debugging

On Arch (and other glibc based distros) it should print a stack trace when that XIO error happens. The backtrace will replace the error string.

When you repro the issue, you should get a backtrace like:

./nsxiv(+0xfccc)[0x563587c61ccc]
/usr/lib/libX11.so.6(_XIOError+0x63)[0x7f75b09a8763]
/usr/lib/libX11.so.6(XNextEvent+0xf9)[0x7f75b0997a99]
./nsxiv(+0xb507)[0x563587c5d507]
./nsxiv(+0xbcaf)[0x563587c5dcaf]
/usr/lib/libc.so.6(+0x23290)[0x7f75b07a3290]
/usr/lib/libc.so.6(__libc_start_main+0x8a)[0x7f75b07a334a]
./nsxiv(+0x4a45)[0x563587c56a45]

For the lines relating to nsxiv, we can run addr2line -e ./nsxiv 0xb507 0xbcaf which would give us the lines right after the one that caused the crash. Please share the backtrace and the result of the addr2line command.

Also took another guess and assumed the problem could be caused by our handling of SIGCHLD. Don't see how but the version in the branch certainly isn't a problem and should have the desired behavior on Linux. So if you suddenly stop being able to repro the issue, I guess we have a fix.

So here's a branch to tryout: https://codeberg.org/TAAPArthur/nsxiv/src/branch/debugging On Arch (and other glibc based distros) it should print a stack trace when that XIO error happens. The backtrace will replace the error string. When you repro the issue, you should get a backtrace like: ``` ./nsxiv(+0xfccc)[0x563587c61ccc] /usr/lib/libX11.so.6(_XIOError+0x63)[0x7f75b09a8763] /usr/lib/libX11.so.6(XNextEvent+0xf9)[0x7f75b0997a99] ./nsxiv(+0xb507)[0x563587c5d507] ./nsxiv(+0xbcaf)[0x563587c5dcaf] /usr/lib/libc.so.6(+0x23290)[0x7f75b07a3290] /usr/lib/libc.so.6(__libc_start_main+0x8a)[0x7f75b07a334a] ./nsxiv(+0x4a45)[0x563587c56a45] ``` For the lines relating to nsxiv, we can run `addr2line -e ./nsxiv 0xb507 0xbcaf` which would give us the lines right after the one that caused the crash. Please share the backtrace and the result of the addr2line command. Also took another guess and assumed the problem could be caused by our handling of SIGCHLD. Don't see how but the version in the branch certainly isn't a problem and should have the desired behavior on Linux. So if you suddenly stop being able to repro the issue, I guess we have a fix.

KodyVB commented

2023-01-19 16:05:35 +00:00

Poster

I'm sorry for the late reply - it's been a really hectic week.

And I'm also sorry to say: I might not be able to help debug anymore. After nearly a decade of using the same computer, I upgraded and can't seem to reproduce the error on my new computer - I just went through 11,000 images on the 76c2b81b branch without error where my old computer would crash after a few hundred consistently.

When I get a day off from work, I could probably throw my old hard drives back into my old computer (which is now acting as a NAS) and try debugging again, but I don't know how many others are even experiencing this issue since only @XPhyro has reproduced it other than me on this thread, so far. But there could just be people seeing the issue is open and not commenting, though.

I'm sorry for the late reply - it's been a really hectic week. And I'm also sorry to say: I might not be able to help debug anymore. After nearly a decade of using the same computer, I upgraded and can't seem to reproduce the error on my new computer - I just went through 11,000 images on the 76c2b81b branch without error where my old computer would crash after a few hundred consistently. When I get a day off from work, I could probably throw my old hard drives back into my old computer (which is now acting as a NAS) and try debugging again, but I don't know how many others are even experiencing this issue since only @XPhyro has reproduced it other than me on this thread, so far. But there could just be people seeing the issue is open and not commenting, though.

👍 1

NRK commented

2023-01-20 17:00:47 +00:00

Owner

I never bothered running nsxiv under thread sanitizer because it's a single threaded program, but TSan seem to be useful even outside of threads. In this case, it caught the sig-handler spoiling the errno #411

Might be bit of a stretch but it's possible that the sighandler's spoiled errno was causing xlib to incorrectly assume some error occurred and thus causing the crash.

EDIT: See the comment below (#391 (comment)) for reproduction steps if anyone else wants to try it out.

I never bothered running nsxiv under thread sanitizer because it's a single threaded program, but TSan seem to be useful even outside of threads. In this case, it caught the sig-handler spoiling the errno #411 Might be bit of a stretch but it's possible that the sighandler's spoiled errno was causing xlib to incorrectly assume some error occurred and thus causing the crash. EDIT: See the comment below (https://codeberg.org/nsxiv/nsxiv/issues/391#issuecomment-778368) for reproduction steps if anyone else wants to try it out.

NRK commented

2023-01-20 17:23:06 +00:00

Owner

Now that I'm looking at it again, No child processes and No such process seems awfully like it's a spoiled errno by waitpid. So I'm quite hopeful that #411 might just be the correct fix for this.

Now that I'm looking at it again, `No child processes` and `No such process` seems awfully like it's a spoiled errno by `waitpid`. So I'm quite hopeful that #411 might just be the correct fix for this.

NRK referenced this issue

2023-01-20 17:31:44 +00:00

don't spoil errno in sig handler #411

NRK commented

2023-01-21 16:39:56 +00:00

Owner

Just realized that if the sighandler was really the cause of this then it should be easy to reproduce.

Open an nsxiv window
Open another terminal and run the following: var=$(pidof nsxiv); while :; do kill -s SIGCHLD $var; done

And boom! I can consistently reproduce it on master now within seconds. Putting the pid into a variable was actually important because doing $(pidof nsxiv) inside the loop actually makes it really hard to reproduce the issue, I presume because of the extra process invocation it was sending less SIGCHLD and so putting it into a variable avoids that overhead and is able to generate more signals.

Trying to do the same on #411 works fine without any crash. So yeah, that confirms that the spoiled errno was definitely the cause of the crash.

Just realized that if the sighandler was really the cause of this then it should be easy to reproduce. * Open an nsxiv window * Open another terminal and run the following: ` var=$(pidof nsxiv); while :; do kill -s SIGCHLD $var; done` And boom! I can consistently reproduce it on `master` now within seconds. Putting the `pid` into a variable was actually important because doing `$(pidof nsxiv)` inside the loop actually makes it really hard to reproduce the issue, I presume because of the extra process invocation it was sending less SIGCHLD and so putting it into a variable avoids that overhead and is able to generate more signals. Trying to do the same on #411 works fine without any crash. So yeah, that confirms that the spoiled `errno` was definitely the cause of the crash.

🎉 1

NRK removed the

help wanted

label 2023-01-21 16:40:13 +00:00

NRK referenced this issue from a commit

2023-01-26 16:26:43 +00:00

don't spoil errno in sig handler (#411)

NRK closed this issue

2023-01-26 16:26:44 +00:00

Crashing when image-info is used #391