Menu
▾
▴
1 Attachments
#60 lircd segfaults if an USB-disk connected and disconnected.
lircd recieves segfault on the some USB-device disconnected.
Description:
lircd segfaults if I disconnect an USB-disk.
Additional info:
I have an USB IR-reciever, driven with atilibusb.
-
package versions
lirc-utils 0.9.1.a-7
libusb 1.0.19-1 -
config and/or log files etc.
core-dump included
Steps to reproduce:
1. start lircd through systemctl: sudo systemctl start lircd
2. start irexec (from user): irexec -d
3. connect the USB-hard-drive (it will automounts through udiskie+udisks2)
4. unmount the drive
5. plug out the drive.
backtrace from gdb
Hm... thanks for this report!
That said, this is not an easy one. Things which might help in hunting this down includes:
Basically, although there is some basic support for hotplugging devices I fear that this is just an example of many shortcomings in this area. However, this seems to be in the driver, so it's sort of localized.
I cannot bring git version to run properly. I stuck at irexec. It says "cannot connect to socket".
:(
Last edit: Ilya Dikarev 2014-11-05
On 05/11/14 12:10, Ilya Dikarev wrote:
git version, right? There is not option to configure. The "official"
name for the runtime option is "loglevel" i. e., --loglevel=debug. It
also accepts "--debug=' for compatibility reasons.
There is some info how to run the git version off the source tree in CONTRIBUTE.md.
Leaving that aside for now, could you post the logs and double-check that the atiusb driver is blacklisted (above)?
I have any module lirc_atiusb installed. Only ati_remote, but it's not loaded.
BTW, looking at that stacktrace again: the basic problem here seems to be that lircd handles the USB disk as a lirc client, and tries to register it. Not surprisingly, the init() routine for the driver fails; after all, a USB disk is not a by any stretch of imagination an IR remote.
Looks like a general problem: lircd does not differ IR-remote usb devices from other USB-devices. This is sort of bad, only reason it's not reported until now is that this is a uncommon usecase. Potentially, this might affect any USB driver, I guess.
But the problem triggers, only if I have irexec running. Without it running, lircd does not segfaults.
On 05/11/14 12:10, Ilya Dikarev wrote:
git version, right? There is no option to configure. The "official" name for the runtime option is "loglevel" i. e., --loglevel=debug. It also accepts "--debug=' for compatibility reasons.
Last edit: Alec Leamas 2014-11-05
[dikiy@localhost daemons]$ ./lircd --nodaemon --plugindir=../plugins/.libs -P /var/tmp/lircd.pid -o /var/tmp/lircd.socket -H atilibusb /etc/lirc/lircd.conf
Warning: cannot open /usr/etc/lirc/lirc_options.conf
lircd: Notice lircd(atilibusb) ready, using /var/tmp/lircd.socket
lircd-0.9.2-devel[8607]: lircd(atilibusb) ready, using /var/tmp/lircd.socket
But when I run irexec from another console, I've got:
[dikiy@localhost tools]$ ./irexec
do_connect: could not connect to socket
connect: No such file or directory
[dikiy@localhost tools]$
Ok. I tested the git-version with the irw-cleint (because irexec dont want run). It seems to be ok withit.
Hm... that's a good sign, indeed. Just to double-check: could you please also try with irexec? You need to inform it about the non-standard socket path:
This is BTW a documentation bug, it's not documented at all :(
I afraid it was too early...
Some testing gives:
run irw
irw works properly, recieves commands from IR.
plug-unplug USB-drive
irw doesn't work properly. But the main process lircd seems continue to run (the forked process segfaults).
restart irw (lircd does not need to be restarted!)
it works properly again
plug-unplug drive
irw continues to work properly!
some logs included.
BTW, lircd from the distro (0.9.1a) seems to produce the same behavior. I need only to kill irexec, and then restart it. After that the lircd-daemon becomes resistance against USB-drives :)
coredump from the git-version.
Hm... just to make it complete: can you attach the batcktrace? I can't read it (no 386 host at hand, my virtual hosting is down).
backtrace here.
Hm... I have no idea about your skills. What should be done here is really to run this in gdb. Have done things like this before?
If so, the first step would be to run lircd with the --nodaemon option. Can you reproduce the error using this? (obviously, this means that you'll need to run irexec/irw in another window).
Please report back before proceeding, there are some libtools oddities to handle...
Last edit: Alec Leamas 2014-11-05
I have alreay started it with --nodaemon:
LD_LIBRARY_PATH=/var/tmp/lirc-git-a0569c712f34bd7be380a94209c23c1992a7a7eb/lib/.libs/ sudo ./lircd --nodaemon --plugindir=../plugins/.libs -P /var/tmp/lircd.pid -o /var/tmp/lircd.socket -H atilibusb -D10 /etc/lirc/lircd.conf
I have some skills in programming. I have used gdb one-two times, but not really "deep".
Well, using gdb "deep" nothing I've done either. Shall we give it a try?
In CONTRIBUTE.md are the commands to invoke gdb. They are for creating a stacktrace, but it's more or less the same. Besides this you need to understand how to set a breakpoint, run the program etc. You will find a tutorial out there, for sure.
One of the things which is interesting here is how ati_init() is called. If you could set a breakpoint on it you should be able to record each time it's called and also to understand if it's for your IR/RF usb dongle or your USB disk.
Another interesting point is the call to usb_read_loop(). As it seems, this is called when the USB disk is removed. But it shouldn't, the checks in ati_init() or rather find_device() should make the driver never to do this.
If you somehow could sort this out it would be a great help.
Ah, the source is in plugins/atilibusb.c; but you already knew that :)
I have a problem: if I switch in gdb to thread 2, irw seems not to react on the IR.
Damned... It was too long since I debugged threaded code. Can you get any meaningful results while sticking to the main thread?
ati_init breakpoint is triggered only when I run irw. USB-drive does not trigger this, while I'm in main thread. usb_loop_.... does not triggered at all.
Last edit: Ilya Dikarev 2014-11-05
OK, that's a lot of good info...
usb_read_loop is in thread 2, lets forget that.
Last point: could you step through find_device(), verifying it returns NULL when called because the USB drive is unplugged?
If it's not called, we have a situation wher the USB drive is installed as the remote device. That can't be, but to make things clear: does the remote work as expected before the crash?
I'll be away for some hours, back later.
I can not catch it from main thread.