More on shutdown segmentation fault

[Aleksander Morgado]

> > 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.
>

I was suggesting to enable dumping core files on SEGFAULT, so that
they can be later on analyzed by gdb (without running MM under gdb)

> 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.
>

Yep, it could be. In theory /dev devices going away shouldn't be an
issue, that already happens on e.g. unplugging a USB device.

-- 
Aleksander