On Mon, Feb 20, 2023 at 05:23:15PM -0800, Stephan Somogyi wrote: > Thx for the reply. > > On Mon, Feb 20, 2023 at 1:36 PM Stuart Henderson <s...@spacehopper.org> > wrote: > > > On 2023/02/20 10:46, Stephan Somogyi wrote: > > > On aarch64 on a RPi3, somewhere between 7.2-current GENERIC.MP#2028 and > > > GENERIC.MP#2033, and the package snapshots that happened around the > > #2033 > > > time,something changed that causes persistent segfaulting while > > executing a > > > perl script that's been unchanged for a year. > > > > The kernel build numbers aren't really helpful in identifying when these > > snapshots were built; dates would be better > > > > I updated to 2028 on Feb 15 and 2033 on Feb 18, so whatever has gone awry > happened in that window. > > I tend to pick up snapshots when the package snapshots update, so every 2-4 > days. I do recall an instance of package snapshot updating around that time > that looked like it updated everything installed, which made me wonder if > clang had been updated, but it appears to still be on 13.0.0.
Perl updated to 5.36 went in on the 14th, so I expect (without proof) that 2028 has perl 5.32.1 and 2033 had perl 5.36.0. > > First off, assuming you're now on a system which is after the perl > > update, make sure you updated all packages and don't have old XS modules > > lying around; you should get no results from > > > > grep '@wantlib perl.22.0' /var/db/pkg/*/+CONTENTS > > > > Nothing returned from that. That's good, but not terribly surprising since the fault happens in python, but still weird. > > (Or if you've built your own Perl native extensions from outside of > > packages then they'll want rebuilding) > > > > I've not built any native extensions for this setup, but good to know. Also good news. > > > The segfault happens when python3 scripts are invoked from within the > > perl > > > script. I'm invoking the python3 scripts via system(); when I then SIGINT > > > via Ctrl-C, the traceback is from within python3.10, suggesting that > > > something that python is sub-launching might be causing the problem, but > > my > > > understanding of python internals is basically zero. > > > > > > If I manually invoke either of the python scripts with identical > > > parameters, everything works, so it's not an innate problem with those > > > scripts or their interaction with python3.10; it's something about how > > > they're being invoked from perl. That I'm not sure about. Very not sure what might be different about that. You wouldn't happen to have a minimally reproducing example, would you? > > > I've tried building minimal repro case perl scripts and am so far > > > unsuccessful; everything works without segfaulting. That's interesting, running the same python script under a different perl script works? Does the failing script set anything in %ENV, or a umask, or anything environment related? > > > I've done enough isolation work now that I'm running into my limits of > > > knowledge and was curious whether this recent behavior rings a bell with > > > anyone here. Grasping at straws, but could this have anything to do with > > > the xonly work? > > > > > > Thanks for any suggestions for how to better identify the root cause and > > > thus generate a more useful bug report. > > > > A backtrace from the segfault might give some clues (pkg_add gdb and > > use the 'egdb' binary; the version of gdb that is in base is not really > > useful in most cases any more) > > > > If I debug the perl instance with egdb, I see the same litany of > uninformative "Segmentation fault" lines that appear to be happening in > python3, but nothing specifically from egdb. I think there's a way to tell gdb to follow into the python process, but off the top of my head I'm not sure what it is. > If I then apply egdb to the python3 invocation inside the perl script, it > tells me that python3 (installed via pkg_add; nothing custom) has no > symbols, and then proceeds to self-quit, whereupon I again just get line > after line of segfaults. sthen will know better, but I think there should be "debug-$package" packages for python to add the symbols. l8rZ, -- andrew At the source of every error which is blamed on the computer, you will find at least two human errors, including the error of blaming it on the computer.
