On Thu, 28 Aug 2014 00:39:44 +0200 =?UTF-8?Q?St=C3=A9phane?=
<steph...@shimaore.net> wrote:
> FWIW I have the issue on one of my machines but not two others; all
> machines are running up-to-date `testing` with lshw B.02.17.
> On the machine that has the issue (SIGSEV), this seems to be in the SCSI
> scanning module in my case; running
> sudo lshw -disable scsi
> does not crash lshw. Given the strace given by the original poster it
> seems to happen in a similar location in their case.
>
> To answer's Leonardo's question, #740034 is referring to an issue that
> crashes the machine when running lshw; here we're facing a bug inside
> lshw (or one of its dependencies).
>
> There are no symbols inside /usr/bin/lshw and no lshw-dbg package so I
> had to build a debug version manually. If I use the orig.tar.gz, apply
> Debian's diff.gz, then start dpkg-buildpackage, the binary src/lshw
> crashes. The stack trace is useless for some reason. However the same
> code (accidentally) compiled using "make" in src/ gives a working lshw;
> I noticed the optimization was different (none in the original Makefile,
> -O2 when compiling for dpkg-buildpackage).
>
> I modified debian/rules to always do -O0 and once installed, the
> resulting lshw does not crash anymore when running `sudo /usr/bin/lshw`.
>
>
Your described my situation exactly. Segfault somewhere on SCSI
scanning, works ok with 'sudo lshw -disable scsi'. I have strace log
similar to that in bugreport and can't give more info without dbg
symbols. I tried to launch lshw with gdb, but it is completely useless.
lshw-gtk also crashes when called with gksu or kdesudo.
--
Best regards,
Boris Egorov
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
