Bug 313281 - gparted crashes when compiled with latest glibc
Summary: gparted crashes when compiled with latest glibc
Alias: None
Product: Fedora
Classification: Fedora
Component: gparted
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Deji Akingunola
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-09-30 20:00 UTC by Deji Akingunola
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-10-30 21:08:52 UTC

Attachments (Terms of Use)
Patch (1010 bytes, patch)
2007-10-30 04:08 UTC, Jim Hayward
no flags Details | Diff

Description Deji Akingunola 2007-09-30 20:00:17 UTC
Description of problem: gparted crashes at runtime when built with
glibc-2.6.90-15. This crash doesn't occur with gparted built just after all the
build-id changes. I'm not sure if its a glibc's bug or gparted's, just wanted to
give it a shot here (bug have been filed with gparted upstream about it).
Backtrace generated while running it under gdb is reproduced below.

Version-Release number of selected component (if applicable): glibc-2.6.90-15

How reproducible: always

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Program received signal SIGABRT, Aborted.
[Switching to Thread 1084229968 (LWP 13286)]
0x0000003eae630b65 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Current language:  auto; currently c
(gdb) bt
#0  0x0000003eae630b65 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x0000003eae632610 in *__GI_abort () at abort.c:88
#2  0x0000003eae66ab8b in __libc_message (do_abort=2, 
    fmt=0x3eae720a7d "*** %s ***: %s terminated\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#3  0x0000003eae6e9522 in *__GI___fortify_fail (
    msg=0x3eae720a4c "buffer overflow detected") at fortify_fail.c:32
#4  0x0000003eae6e7c40 in *__GI___chk_fail () at chk_fail.c:29
#5  0x0000003eae6e827b in __realpath_chk (
    buf=0x33e3 <Address 0x33e3 out of bounds>, 
    resolved=0x33e6 <Address 0x33e6 out of bounds>, resolvedlen=6)
    at realpath_chk.c:30
#6  0x000000000044fdcd in GParted::GParted_Core::init_maps (
    this=<value optimized out>) at /usr/include/bits/stdlib.h:35
#7  0x000000000045024f in GParted::GParted_Core::set_devices (
    this=0x7fffe43e8820, devices=@0x7fffe43e7eb8) at GParted_Core.cc:146
#8  0x000000000046bb87 in GParted::Win_GParted::thread_refresh_devices (
    this=0x7fffe43e7cf0) at Win_GParted.cc:958
#9  0x0000003eb5a3358f in call_thread_entry_slot (data=<value optimized out>)
    at /usr/include/sigc++-2.0/sigc++/functors/slot.h:440
#10 0x0000003eb3a507e4 in g_thread_create_proxy (data=0x832210)
    at gthread.c:635
---Type <return> to continue, or q <return> to quit---
#11 0x0000003eaf206447 in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#12 0x0000003eae6d3e5d in clone () from /lib64/libc.so.6

Comment 1 Jakub Jelinek 2007-09-30 20:16:08 UTC
That is a bug in gparted.
See http://www.opengroup.org/onlinepubs/009695399/functions/realpath.html
The buffer pointed to by second argument must be at least PATH_MAX bytes long,
or the second argument to realpath must be NULL (GNU extension and upcoming
POSIX version; if NULL, the buffer is malloced).

Comment 2 Deji Akingunola 2007-09-30 21:14:50 UTC

Thanks for explanation. I 'fixed' it by using NULL as the second argument, and
the crash is gone. 

Comment 3 Jakub Jelinek 2007-09-30 21:54:01 UTC
Please make sure that what realpath returned is then freed, otherwise you
introduced a memory leak.

Comment 4 Jim Hayward 2007-10-30 04:08:23 UTC
Created attachment 242691 [details]

This isn't the best way to fix this since realpath(path, NULL) is a
non-standard GNU extension. Definitely not how I would consider fixing this
upstream (the upstream project appears to be dead). But since this effects the
Fedora package only, I don't really see a problem.

Comment 5 Deji Akingunola 2007-10-30 21:08:52 UTC
Thanks for the patch Jim, applied.

Note You need to log in before you can comment on or make changes to this bug.