hdparm crashed with SIGSEGV in __libc_start_main()

Bug #396837 reported by Martin Erik Werner
78
This bug affects 11 people
Affects Status Importance Assigned to Milestone
hdparm (Ubuntu)
Fix Released
High
Canonical Foundations Team
Karmic
Fix Released
High
Canonical Foundations Team

Bug Description

Binary package hint: hdparm

Crash reported immediately after boot. Similar bugs reported, but for suspend-to-ram (#395971, #393674). Related?

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Fri Jul 3 08:52:06 2009
Dependencies:
 findutils 4.4.2-1
 gcc-4.4-base 4.4.0-8ubuntu2
 libc6 2.9-9ubuntu2
 libgcc1 1:4.4.0-8ubuntu2
DistroRelease: Ubuntu 9.10
ExecutablePath: /sbin/hdparm
NonfreeKernelModules: nvidia
Package: hdparm 9.15-1ubuntu1
ProcCmdline: hdparm -B 254 /dev/sdb
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, no user)
ProcVersionSignature: Ubuntu 2.6.30-9.10-generic
SegvAnalysis:
 Segfault happened at: 0x4044d8 <sync@plt+12088>: movzwl 0xa6(%rdx),%eax
 PC (0x004044d8) ok
 source "0xa6(%rdx)" (0x000000a6) not located in a known VMA region (needed readable region)!
 destination "%eax" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: hdparm
StacktraceTop:
 ?? ()
 ?? ()
 __libc_start_main () from /lib/libc.so.6
 ?? ()
 ?? ()
Title: hdparm crashed with SIGSEGV in __libc_start_main()
Uname: Linux 2.6.30-9-generic x86_64
UserGroups:

Related branches

Revision history for this message
Martin Erik Werner (arand) wrote :
visibility: private → public
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt (retraced)

StacktraceTop:?? ()

Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt (retraced)
tags: added: apport-failed-retrace
tags: removed: need-amd64-retrace
Revision history for this message
Nick Ellery (nick.ellery) wrote :

Got the same crash coming out of suspend.

Changed in hdparm (Ubuntu):
status: New → Confirmed
Revision history for this message
William Bohn (shambler) wrote :

I get the same crash coming out of suspend on an i386 architecture.

Revision history for this message
Martin Pitt (pitti) wrote :

Got a local retrace which is better:

--- stack trace ---
#0 0x00000000004044d8 in process_dev (devname=0x0) at hdparm.c:1826
        fd = 3
        err = 52
        parm = 0
        multcount = 0
        id = 0x0
#1 0x0000000000406d29 in main (_argc=<value optimized out>, _argv=<value optimized out>) at hdparm.c:2399
        no_more_flags = 0
        disallow_flags = 0
        c = <value optimized out>
        name = "\1\0\0\0}0\264,0\344@", '\0' <repeats 13 times>, ";\22@\0\0\0\0"
--- thread stack trace ---
.
Thread 1 (Thread 3074):
#0 0x00000000004044d8 in process_dev (devname=0x0) at hdparm.c:1826
        fd = 3
        err = 52
        parm = 0
        multcount = 0
        id = 0x0
#1 0x0000000000406d29 in main (_argc=<value optimized out>, _argv=<value optimized out>) at hdparm.c:2399
        no_more_flags = 0
        disallow_flags = 0
        c = <value optimized out>
        name = "\1\0\0\0}0\264,0\344@", '\0' <repeats 13 times>, ";\22@\0\0\0\0"
--- source code stack trace ---
#0 0x00000000004044d8 in process_dev (devname=0x0) at hdparm.c:1826
  1821: }
  1822: }
  1823: if (get_apmmode) {
  1824: id = get_identify_data(fd, id);
  1825: printf(" APM_level = ");
  1826: if((id[83] & 0xc008) == 0x4008) {
  1827: if (id[86] & 0x0008)
  1828: printf("%u\n", id[91] & 0xff);
  1829: else
  1830: printf("off\n");
  1831: } else
#1 0x0000000000406d29 in main (_argc=<value optimized out>, _argv=<value optimized out>) at hdparm.c:2399
  2394: while (argc--) {
  2395: argp = *argv++;
  2396: if (no_more_flags || argp[0] != '-') {
  2397: if (!num_flags_processed)
  2398: do_defaults = 1;
  2399: process_dev(argp);
  2400: continue;
  2401: }
  2402: if (0 == strcmp(argp, "--")) {
  2403: no_more_flags = 1;
  2404: continue;

So clearly id == NULL here, and id[83] crashes.

Changed in hdparm (Ubuntu):
assignee: nobody → Canonical Foundations Team (canonical-foundations)
importance: Undecided → High
Revision history for this message
Robbie Williamson (robbiew) wrote :

I see you had the 2.6.30 kernel running, is this reproducible with the latest Karmic kernel (2.6.31-2.17)?

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 396837] Re: hdparm crashed with SIGSEGV in __libc_start_main()

Robbie Williamson [2009-07-13 14:27 -0000]:
> I see you had the 2.6.30 kernel running, is this reproducible with the
> latest Karmic kernel (2.6.31-2.17)?

Yes, I'm on 2.6.31-2.17.

Revision history for this message
Colin Watson (cjwatson) wrote :

The bug itself is easy to fix, but I'd like to get a bit of extra detail while people's attention is on this bug, just in case this is triggered by some underlying problem that we can fix at the same time. Could somebody who can reproduce this bug please run:

  for device in /dev/[sh]d[a-z]; do sudo DEVNAME="$device" strace -f -o hdparm-"$(basename $device)".trace -s 1024 /lib/udev/hdparm; done

... and then attach all the hdparm-*.trace files to this bug?

Changed in hdparm (Ubuntu Karmic):
status: Confirmed → Incomplete
Revision history for this message
Colin Watson (cjwatson) wrote :

Oh, please also attach /etc/hdparm.conf.

Revision history for this message
Colin Watson (cjwatson) wrote :

Actually, on investigation, I don't think it's the udev rule that's firing, but rather /etc/acpi/start.d/90-hdparm.sh or similar. It'd be best to get an strace of whichever hdparm -B command is being used in there ...

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package hdparm - 9.15-1ubuntu2

---------------
hdparm (9.15-1ubuntu2) karmic; urgency=low

  * Fix crash with -B when HDIO_DRIVE_CMD(identify) fails (LP: #396837).

 -- Colin Watson <email address hidden> Tue, 14 Jul 2009 14:04:15 +0100

Changed in hdparm (Ubuntu Karmic):
status: Incomplete → Fix Released
Revision history for this message
Nick Ellery (nick.ellery) wrote :

Fix works for me, no more crash upon resuming from suspend.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.