Bugzilla – Bug 15861
SetupStorage applet doesn't validity check values, potentially crashing SP
Last modified: 2010-03-09 11:29:32 UTC
Vahid reported fab4 crashing when accessing the "USB & SD Storage" item while a scan was running. Looking at the log I see the following lines: Mar 8 21:44:23 watchdog[621]: repair binary returned 2 Mar 8 21:44:23 watchdog[621]: shutting down the system because of error 2 Mar 8 21:44:23 squeezeplay: WARN squeezeplay - quit_hook:275 stack traceback: Mar 8 21:44:23 squeezeplay: [C 0x51815]: in function '(for generator)' Mar 8 21:44:23 squeezeplay: ...are/jive/applets/SetupStorage/SetupStorageApplet.lua:98: in function 'doDevicesValues' Mar 8 21:44:23 squeezeplay: ...are/jive/applets/SetupStorage/SetupStorageApplet.lua:137: in function 'showDevicesMenu' Mar 8 21:44:23 squeezeplay: ...are/jive/applets/SetupStorage/SetupStorageApplet.lua:405: in function 'callback' Mar 8 21:44:23 squeezeplay: /usr/share/jive/jive/ui/SimpleMenu.lua:189: in function 'itemListener' Mar 8 21:44:23 squeezeplay: /usr/share/jive/jive/ui/Menu.lua:154: in function </usr/share/jive/jive/ui/Menu.lua:149> Mar 8 21:44:23 squeezeplay: (tail Mar 8 21:44:33 udhcpc[807]: Sending renew... Mar 8 21:44:33 syslogd exiting Line 98 refered to is trying to iterate over io.popen("/bin/df") without checking the validity of that handle. I guess this is causing the crash if the handle is invalid.
Created attachment 6619 [details] Vahid's log file
Alan thinks it's rather the blocking character of the two io.popen() calls. df can take quite a few seconds to return. Maybe this is triggering the watchdog on heavy load situations like when scanning for music.
This might be a related bug 15146
I did some tests and adding a task seems not to be enough to fix it. The call to 'blkid' seems to work ok, but the call to 'df' fails even though the handle looks like a valid file: Mar 9 12:57:05 squeezeplay: INFO applet.SetupStorage - SetupStorageApplet.lua:105 ** df: file (0x87aa08) But I also see this in Vahid's and my logs: Mar 9 12:57:22 watchdog[620]: semaphore 692:0 was not changed. Not sure what that means. Maybe some underlying code 'df' is using is not re-entrant or something?
This is a dupe of bug 15146 where the waiting time was too long for the watchdog to wait. It's not as patient as Mickey, thus killing the player. *** This bug has been marked as a duplicate of bug 15146 ***
(In reply to comment #5) > This is a dupe of bug 15146 where the waiting time was too long for the > watchdog to wait. It's not as patient as Mickey, thus killing the player. > > *** This bug has been marked as a duplicate of bug 15146 *** Even though the cause of the bug seems to be the same, but this is not a duplicate, considering the fact that this will caused the Fab4 to reset.