-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGPWR signal on Debian #552
Comments
@michaellilltokiwa, I failed to reproduce the issue. I used the following command to build and run test: |
@michaellilltokiwa commented 2 hours ago: @ivmai I used clang originally: but it seems to be the same with gcc: sam@debian /home/not_synced/bdwgc (master)$ gcc -I include -DGC_THREADS test_process.c extra/gc.c -lpthread For help, type "help". Thread 1 "a.out" received signal SIGPWR, Power fail/restart. Thread 1 "a.out" received signal SIGXCPU, CPU time limit exceeded. @michaellilltokiwa commented 1 hour ago: It seems that this problem does not occur on every execution.
|
I've executed the code 10K times and haven't seen any crash.
I should tell you that this is normal on Linux platform - SIGPWR and SIGXCPU are sued by libgc internally to suspend and resume threads. |
On behalf of @michaellilltokiwa (moved from #544 ):
I hit an issue that seems to be very similar to this. Using libgc1 Version on debian is 8.2.2-3
Attached is a the source code to reproduce the issue. SIGPWR.zip
PS:
The C-code is generated by the Fuzion compiler so unfortunately it is ~60000 lines long but what 'm trying to do is simple.
I'm starting a process cat and in a thread, start reading from a pipe connected to its stdout.
In the main thread I'm sleeping for 10 sec.
I cloned this https://github.com/ivmai/bdwgc then tried both flags, followed by rebuilding libgc: make clean, ./configure.sh, make. I also made sure with strace that my program is not using the debian libgc:
sam@debian ~/n/fuzion (lib/process_wip_strange_err)$ strace ./test_process 2>&1 |grep open
...
openat(AT_FDCWD, "/home/not_synced/bdwgc/.libs/libgc.so.1", O_RDONLY|O_CLOEXEC) = 3
...
It did not seem to make a difference.
Yes, it is still reproducible.
The text was updated successfully, but these errors were encountered: