[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crashes with latest gtk+2.0-2.2.2 package



Hi.

Several days ago I wrote this:
> 
> I've installed it and found a problem I'm trying to see if others see it 
> or if the problem is localized. When the GTK File Open dialog opens or
> closes I'm very likely to see the program crash, and it isn't just a
> single GTK application. I've built much of GNOME from CVS and have seen
> eog and gnumeric hang when the dialog box is being removed. I also use
> pygtk and can generate a crash in python when this dialog widget
> appears. My pygtk build is also from yesterday's CVS.
> 

I've been fiddling with strace and now think the problem is memory
corruption possibly due to the GtkFileSel patch. The corruption is
definitely happening when the directory contents are read loaded.

$ export MALLOC_CHECK_=2
$ strace -o eog.out eog
[ ... eog starts, I click on the 'Open' button, program dies ... ]

Here's the tail end of the strace output:

.....
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}], 6, 0) = 0
write(3, "5\20\4\0E\0@\1+\0@\0010\0005\0007\0\6\0F\0@\1E\0@\1\4\0"..., 1480) = 1480
read(3, "\1\0014\3\0\0\0\0\3\0@\1\0\0\0\0\4\0\0\0\0\0\0\0\310\250"..., 32) = 32
ioctl(3, FIONREAD, [0])                 = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN, revents=POLLIN}, {fd=8, events=POLLIN}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}], 6, -1) = 1
ioctl(3, FIONREAD, [64])                = 0
read(3, "\5\0014\3\332\24\317\0047\0\0\0/\0@\1\0\0\0\0\366\0\f\1"..., 64) = 64
getcwd("/home/arth", 4096)              = 11
stat64("/afs", 0xbfffdad0)              = -1 ENOENT (No such file or directory)
stat64("/net", 0xbfffdad0)              = -1 ENOENT (No such file or directory)
stat64("/home/arth", {st_mode=S_IFDIR|S_ISGID|0755, st_size=16384, ...}) = 0
open("/home/arth", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 13
fstat64(13, {st_mode=S_IFDIR|S_ISGID|0755, st_size=16384, ...}) = 0
fcntl64(13, F_SETFD, FD_CLOEXEC)        = 0
getdents64(13, /* 120 entries */, 4096) = 4096
getdents64(13, /* 117 entries */, 4096) = 4088
getdents64(13, /* 114 entries */, 4096) = 4072
getdents64(13, /* 109 entries */, 4096) = 4088
getdents64(13, /* 105 entries */, 4096) = 4080
getdents64(13, /* 104 entries */, 4096) = 3888
getdents64(13, /* 0 entries */, 4096)   = 0
lseek(13, 0, SEEK_SET)                  = 0
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
kill(8292, SIGABRT)                     = 0
--- SIGABRT (Aborted) @ 0 (0) ---
write(3, "\33\20\2\0\0\0\0\0", 8)       = 8
write(3, " \20\2\0\0\0\0\0", 8)         = 8
write(3, "+\20\1\0", 4)                 = 4
read(3, "\1\0017\3\0\0\0\0\3\0@\1\1\0\0\0\4\0\0\0\0\0\0\0\310\250"..., 32) = 32
fork()                                  = 8305
waitpid(8305, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0) = 8305
--- SIGCHLD (Child exited) @ 0 (0) ---
sigreturn()                             = ? (mask now [ABRT RTMIN])
exit_group(1)                           = ?

Note the stating of '/afs' and '/net'. This occurs in gtk/filesel.c in
the check_dir() function. This function is called in the open_dir()
function in the same file. It looks like check_dir() succeeds, then the
open_dir() function calls open_new_dir(), when the directory is opened
and the contents read in. Based on the strace output the directory
contents get counted, the directory filehandle is repositioned to the
beginning of the file, then things go splat.

I'm running the libc6-2.3.2 package that was test released about 10 days
ago or so, but the 2.3.2 package has now made it into unstable so
perhaps this memory corruption I'm seeing will present itself to other
people who run with this new libc6 package.

Can anyone duplicate this?

Art Haas

-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822



Reply to: