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 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 (Or if you've built your own Perl native extensions from outside of packages then they'll want rebuilding) > 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. > > I've tried building minimal repro case perl scripts and am so far > unsuccessful; everything works without segfaulting. > > 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)
