More on shutdown segmentation fault

[Peter Naulls]

On 12/6/22 08:07, Aleksander Morgado wrote:

> 
> MM shouldn't write to any file, apart from the log file if you used
> --log-file=[PATH].
> MM does read from several files in the filesystem, but that shouldn't
> be an issue unless your system is limiting access to certain paths
> only. Is this the case?

That is the case, and the point. During shutdown, various parts of
the system go away, certainly /dev, /sys, /overlay, /tmp.  The problem
might not be a file, it might be a device or socket.  I'm just trying
to give some clues as to where to look.

Here's lsof:

3714    /usr/sbin/ModemManager  0       /dev/null
3714    /usr/sbin/ModemManager  1       /dev/null
3714    /usr/sbin/ModemManager  2       /dev/null
3714    /usr/sbin/ModemManager  3       anon_inode:[eventfd]
3714    /usr/sbin/ModemManager  4       anon_inode:[eventfd]
3714    /usr/sbin/ModemManager  5       socket:[19212]
3714    /usr/sbin/ModemManager  6       anon_inode:[eventfd]
3714    /usr/sbin/ModemManager  7       socket:[1058312]
3714    /usr/sbin/ModemManager  8       /dev/ttyUSB3
3714    /usr/sbin/ModemManager  9       /dev/ttyUSB0
3714    /usr/sbin/ModemManager  11      /dev/ttyUSB2

> Looking at the error it does look like a NULL pointer dereference of
> some sort. Does the system generate core files, and if so, could we
> debug one with gdb to get a full backtrace of where the issue
> happened?

My previous experiments with gdb show it to run far too slowly for ModemManager
to operate correctly - various timeouts kick in, and it doesn't want to
connect.

Unfortunately, I'm not in a position to investigate this much more this week -
my current work involves rapid turn around of images, and I'm doing things
with overlay, during which I noticed this as well, although that might just
be coincidence.

I realize this could well be a libglib problem too.