parted_server crashed with SIGSEGV in __libc_start_main()

Bug #973450 reported by Peter Hurley
30
This bug affects 3 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Expired
Medium
Unassigned

Bug Description

Crash with amd64 desktop iso of 4/4/12.

Boot from DVD, select 'Try Ubuntu', then 'Install Ubuntu 12.04'. Occurs after selecting 'Continue' from the 'Preparing to install Ubuntu'.

Hopefully the problem with mismatched debug symbols has been fixed :)

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: ubiquity 2.10.6
ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
Uname: Linux 3.2.0-21-generic x86_64
ApportVersion: 2.0-0ubuntu4
Architecture: amd64
CasperVersion: 1.314
Date: Wed Apr 4 14:42:28 2012
ExecutablePath: /bin/parted_server
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity
LiveMediaBuild: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120404)
ProcCmdline: parted_server
ProcEnviron:
 TERM=unknown
 LC_COLLATE=C
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: ubiquity
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
 ?? ()
Title: parted_server crashed with SIGSEGV in __libc_start_main()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

Revision history for this message
Peter Hurley (phurley) wrote :
Revision history for this message
Peter Hurley (phurley) wrote :
Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceTop.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in ubiquity (Ubuntu):
status: New → Invalid
Revision history for this message
Apport retracing service (apport) wrote : Crash report cannot be processed

Thank you for your report!

However, processing it in order to get sufficient information for the
developers failed (it does not generate a useful symbolic stack trace). This
might be caused by some outdated packages which were installed on your system
at the time of the report:

outdated debug symbol package for dmidecode: package version 2.11-4 dbgsym version 2.9-1.2build1
outdated debug symbol package for cryptsetup: package version 2:1.4.1-2ubuntu2 dbgsym version 2:1.1.3-4ubuntu2

Please upgrade your system to the latest package versions. If you still
encounter the crash, please file a new report.

Thank you for your understanding, and sorry for the inconvenience!

tags: removed: need-amd64-retrace
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/973450

tags: added: iso-testing
Peter Hurley (phurley)
Changed in ubiquity (Ubuntu):
status: Invalid → New
visibility: private → public
Revision history for this message
Steve Langasek (vorlon) wrote :

Unfortunately, it looks like we still don't have a full stack trace for this. Since the problem is not widely reproducible, we are unlikely to be able to debug this without a stack trace.

Can you install the -dbgsym packages in the live environment before starting the installer, and generate a full backtrace locally?

Changed in ubiquity (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Peter Hurley (phurley) wrote :

Hi Steve,

I can but not until Monday or Tuesday of next week.

Revision history for this message
Peter Hurley (phurley) wrote :

Hi Steve,

What -dbgsym packages can I install locally to get a valid stack trace???

FYI - The outdated debug symbol packages I've reported on a separate bug# 962479 against apport which Martin just invalidated. He stated that it's due to outdated binary packages but that doesn't make sense -- dmidecode is still at 2.11-4 !!

Revision history for this message
Peter Hurley (phurley) wrote :

Ok, here's the situation:

There is no stack backtrace because there is no debug symbol package for parted_server (which is a binary produced from ubiquity source package in d-i/source/partman-base/parted_server.c)

Despite that, simply loading parted_server in gdb and disassembling at the fault address was sufficient to uncover the faulting code. In parted_server.c::command_get_file_system(), the following line will fault if fs_type == NULL:
                        if (0 == strncmp(part->fs_type->name, "linux-swap", 10))

Although this should be fixed, there is a larger problem that is contributing to this: the scripts feeding the parted_server are mistaking /dev/mapper partitions as devices.

Here's the output from parted_devices on my machine:
peter@thor:~/src/packages/ubiquity/ubiquity-2.10.8/d-i/source/partman-base$ sudo ./parted_devices
[sudo] password for peter:
/dev/sda 1000204886016 ATA WDC WD1001FALS-0
/dev/sdb 1000204886016 ATA WDC WD1001FALS-0
/dev/sdc 250000000000 ATA ST3250310AS
/dev/sdd 160041885696 Seagate FreeAgent Go
/dev/mapper/isw_cbdbfhdjad_Raid0p6 940568928768 Linux device-mapper (linear)
/dev/mapper/isw_cbdbfhdjad_Raid0p1 1048575112704 Linux device-mapper (linear)
/dev/mapper/isw_cbdbfhdjad_Raid0p5 11260376064 Linux device-mapper (linear)
/dev/mapper/isw_cbdbfhdjad_Raid0p2 951829338112 Linux device-mapper (linear)
/dev/mapper/isw_cbdbfhdjad_Raid0 2000405397504 Linux device-mapper (striped)

Now, if you look at the partman log attached to this bug report, you'll see that parted_server is being fed the /dev/mapper/...._Raid0p2, for example, as a device. This is *way wrong* -- look at the crazy partition table it came up with for this "device":

/lib/partman/init.d/35dump: IN: DUMP =dev=mapper=isw_cbdbfhdjad_Raid0p2
parted_server: Read command: DUMP
parted_server: command_dump()
parted_server: Opening outfifo
parted_server: OUT: OK

parted_server: Closing infifo and outfifo
parted_server: main_loop: iteration 20
parted_server: Opening infifo
Device: yes
Model: Linux device-mapper (linear)
Path: /dev/mapper/isw_cbdbfhdjad_Raid0p2
Sector size: 512
Sectors: 1859041676
Sectors/track: 63
Heads: 255
Cylinders: 115719
Partition table: yes
Type: msdos
Partitions: # id length type fs path name
(0,0,0) (0,0,1) -1 0-1023 1024 primary label /dev/mapper/isw_cbdbfhdjad_Raid0p2p-1
(0,0,2) (114350,253,1) 2 1024-940568929791 940568928768 primary extended /dev/mapper/isw_cbdbfhdjad_Raid0p2p2
(0,0,2) (114350,253,1) 5 1024-940568929791 940568928768 logical ext4 /dev/mapper/isw_cbdbfhdjad_Raid0p2p5
(114350,253,2) (114350,254,1) -1 940568929792-940568962047 32256 pri/log free /dev/mapper/isw_cbdbfhdjad_Raid0p2p-1
(114350,254,2) (115719,253,1) 1 940568962048-951829338111 11260376064 primary linux-swap /dev/mapper/isw_cbdbfhdjad_Raid0p2p1
Dump finished.

This mishandling of fakeraid partitions should be easily reproducible on any fakeraid machine.

FYI - the "outdated debug symbol packages" bug is a red herring. No stack trace is possible because there are no debug symbol packages for parted_server.

Peter Hurley (phurley)
Changed in ubiquity (Ubuntu):
status: Incomplete → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Revision history for this message
Peter Hurley (phurley) wrote :

Still broken on quantal....

Peter Hurley (phurley)
Changed in ubiquity (Ubuntu):
status: Confirmed → New
Revision history for this message
Marcus Tomlinson (marcustomlinson) wrote :

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

Changed in ubiquity (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]

Changed in ubiquity (Ubuntu):
status: Incomplete → Expired
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.