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.
