Closed xexyl closed 9 months ago
I'll do more tomorrow. Good day!
Somewhere in the last few pull requests @xexyl, make test
fails on RHEL Linux and macOS:
bug-report.20230801.092356.txt
The above report is from macOS where it does not crash.
Somewhere in the last few pull requests @xexyl,
make test
fails on RHEL Linux and macOS:
Strange that it fails in macOS as I tested it there .. I wonder. I'll take a look quickly.
I'm confused. The script says all tests passed. Can you provide more information? This is what I see in the log:
All tests PASSED
A log of the above tests was saved to bug-report.20230801.092356.txt.
If you feel everything is in order you may safely delete that file.
Otherwise you may report the issue at the GitHub issue page:
https://github.com/ioccc-src/mkiocccentry/issues
making sure to attach bug-report.20230801.092356.txt with your report. You may
instead email the Judges but you're encouraged to file a
report instead. This is because not all tools were written by
the Judges.
on RHEL Linux, make test
does:
test_jparse: make test starting
./jparse_test.sh -L -j ../jparse -p ./print_test -d test_JSON -s . ./json_teststr.txt ./jparse_test.sh: line 495: 1073649 Segmentation fault (core dumped) "$print_test" -v "$dbg_level" >> "${LOGFILE}" 2>&1 NOTE: the print_test test failed. See the log for details. test_jparse: ERROR: jparse_test.sh failed, error code: 2 make[2]: [Makefile:393: test] Error 2 make[1]: [Makefile:671: test] Error 2 make: *** [Makefile:899: test] Error 2
on RHEL Linux,
make test
does:test_jparse: make test starting
./jparse_test.sh -L -j ../jparse -p ./print_test -d test_JSON -s . ./json_teststr.txt ./jparse_test.sh: line 495: 1073649 Segmentation fault (core dumped) "$print_test" -v "$dbg_level" >> "${LOGFILE}" 2>&1 NOTE: the print_test test failed. See the log for details. test_jparse: ERROR: jparse_test.sh failed, error code: 2 make[2]: [Makefile:393: test] Error 2 make[1]: [Makefile:671: test] Error 2 make: *** [Makefile:899: test] Error 2
My guess is that's a bug in print_test
.
Yes it crashes in linux.
Previous bug report was for macOS, but RHEL linux crashes:
It has to do with vdprintf().
Going to wake up now and do stuff .. best wishes.
This crashes in linux:
ret = vdprintf(fileno(stdout), fmt, ap);
But why? Was stdout closed or made invalid somehow? Should it be removed?
Here's a backtrace:
Reading symbols from print_test...
[New LWP 2079555]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `./print_test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
76 VPCMPEQ (%rdi), %ymm0, %ymm1
(gdb) bt
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:76
#1 0x00007f8ef50c9101 in __printf_buffer (buf@entry=0x7ffca188b240, format@entry=<optimized out>, ap@entry=<optimized out>,
mode_flags@entry=<optimized out>) at /usr/src/debug/glibc-2.37-4.fc38.x86_64/stdio-common/vfprintf-process-arg.c:435
#2 0x00007f8ef50e9bfb in __vdprintf_internal (d@entry=<optimized out>, format@entry=<optimized out>, arg@entry=<optimized out>,
mode_flags@entry=<optimized out>) at iovdprintf.c:69
#3 0x0000000000402db7 in vprint_test (fmt@entry=<optimized out>) at print_test.c:455
#4 0x00000000004025f6 in main (argc@entry=<optimized out>, argv@entry=<optimized out>) at print_test.c:163
Doing other things now though .. can look at it tomorrow if you don't have any ideas. Seems strange. I don't have any problems in macOS and the bug_report.sh doesn't how any problems either.
Given the backtrace it seems like it might be the string but why? I don't know.
This crashes in linux:
ret = vdprintf(fileno(stdout), fmt, ap);
Instead of trying to be compact, expand you C:
fd = fileno(stdout);
dbg(DBG_MED, "fd for stdout: %d", fd);
ret = vdprintf(fd, fmt, ap);
...
Also check to be sure that fmt is still valid. Check ap is still within scope. Check that the args in ap match what fmt is expecting.
This crashes in linux:
ret = vdprintf(fileno(stdout), fmt, ap);
Instead of trying to be compact, expand you C:
fd = fileno(stdout); dbg(DBG_MED, "fd for stdout: %d", fd); ret = vdprintf(fd, fmt, ap); ...
Can do that too.
Also check to be sure that fmt is still valid. Check ap is still within scope. Check that the args in ap match what fmt is expecting.
Already did but I will again or maybe make it a new function.
We are working on the vprint_test() function ...
We independently found a lack of firewall issue with the dbg repo. While this is NOT related to this bug, we are going to correct that issue as well as working on making print_test.c
much more robust. Stay tuned as we are working on both ...
We have addressed the dbg repo issue. We are going to think about the changes and then return to making print_test.c much more robust. Stay tuned as we are working on both ...
With commit b720f1c260fe2c04c1b41811727445595f3fd2c0, the dbg repo has been updated to release dbg 2.10 2023-08-01. With commit b0dccb5c03533a70795eaed6df409e6d5f4da826, the dbg facility in this repo has been updated to the same version.
Now to fix print_test.c ...
With commit 7c3adbfc79219430373025afa13cff48e7975ea6 print_test has been fixed.
With commit 7c3adbf print_test has been fixed.
Thanks! Saves me the effort of having to do it. Still mostly asleep so I won't be doing anything yet but I hope to either get back to sleep for a bit or wake up soon so that maybe I can work on the man pages. We'll see.
With commit b720f1c260fe2c04c1b41811727445595f3fd2c0, the dbg repo has been updated to release dbg 2.10 2023-08-01. With commit b0dccb5, the dbg facility in this repo has been updated to the same version.
Thanks! I pulled my fork of dbg too so I have it up to date. Appreciate the note and glad you found the problem.
The macros were changed but the man page was not updated.