View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001241 | libextractor | plugins | public | 2007-06-28 14:13 | 2007-07-04 18:14 |
| Reporter | romainc | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | crash | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | 0.5.18 | ||||
| Summary | 0001241: libextractor_ole2 crashes | ||||
| Description | On my computer, it crashes, but not on another one. When I move libextractor_ole2 on another place, it works. here a the end of a strace on $ strace extract /usr/share/doc/texlive-pstricks/generic/pstricks/voss/bsp02.pdf : open("/usr/lib/libextractor/libextractor_nsf.la", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=990, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7aba000 read(3, "# libextractor_nsf.la - a libtoo"..., 4096) = 990 read(3, "", 4096) = 0 close(3) = 0 munmap(0xb7aba000, 4096) = 0 open("/usr/lib/libextractor/libextractor_nsf.so", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360\3\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0644, st_size=3832, ...}) = 0 mmap2(NULL, 6800, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7893000 mmap2(0xb7894000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xb7894000 close(3) = 0 stat64("/usr/share/doc/texlive-pstricks/generic/pstricks/voss/bsp02.pdf", {st_mode=S_IFREG|0644, st_size=19797, ...}) = 0 open("/usr/share/doc/texlive-pstricks/generic/pstricks/voss/bsp02.pdf", O_RDONLY|O_LARGEFILE) = 3 mmap2(NULL, 19797, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb788e000 open("/usr/lib/charset.alias", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) write(2, "\n** (process:5114): CRITICAL **:"..., 106 ** (process:5114): CRITICAL **: gsf_input_memory_get_type: assertion `gsf_input_memory_type != 0' failed ) = 106 write(2, "\n(process:5114): GLib-GObject-CR"..., 107 (process:5114): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed ) = 107 write(2, "\n** (process:5114): CRITICAL **:"..., 108 ** (process:5114): CRITICAL **: gsf_shared_memory_get_type: assertion `gsf_shared_memory_type != 0' failed ) = 108 write(2, "\n(process:5114): GLib-GObject-CR"..., 107 (process:5114): GLib-GObject-CRITICAL **: g_object_new: assertion `G_TYPE_IS_OBJECT (object_type)' failed ) = 107 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Process 5114 detached | ||||
| Tags | No tags attached. | ||||
|
|
What does $ ldd /usr/lib/libextractor.so report? (use whatever path libextractor.so is at). |
|
|
$ ldd /usr/lib/libextractor.so linux-gate.so.1 => (0xffffe000) libltdl.so.3 => /usr/lib/libltdl.so.3 (0xb7f4f000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f4b000) libz.so.1 => /usr/lib/libz.so.1 (0xb7f35000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7f25000) libgsf-1.so.114 => /usr/lib/libgsf-1.so.114 (0xb7ef0000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7eb6000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb7d99000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb7d06000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7bc3000) /lib/ld-linux.so.2 (0x80000000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7b9b000) |
|
|
Looks to me like something for jody@gnome.org (GSF maintainer). |
|
|
You are right, this is a gsf related bug, I downgraded libgsf debian package from version 1.4.4 to version 1.4.3, and now, no more segfault. |
|
|
I've frequently had trouble communicating with the libgsf maintainer (bad spam filter?). So you might want to file this one with the Debian libgsf package as well (just to catch his attention...). |
|
|
Hi ! I recieved a response from the libgsf maintainer : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431104 He told that |
|
|
I don't think that is the cause. Here is what the OLE2 plugin looks like: void __attribute__ ((constructor)) ole2_ltdl_init() { #ifdef gsf_init gsf_init(); #endif // gsf_init_dynamic(NULL); } void __attribute__ ((destructor)) ole2_ltdl_fini() { #ifdef gsf_init gsf_shutdown(); #endif // gsf_shutdown_dynamic(NULL); } In other words, we *do* call gsf_init. Here is what Jody Goldberg (libgsf maintainer) wrote to me personally: It's almost certianly related to a glib thredaing issue that we've hit due to the transition to dynamic types we made for libextractor. Unfortunately, I'm going to have to do a 1.14.5 that reverses the gsf_init_dynamic support until glib gets it's act together. |
|
|
I'm the one who claimed the ole2 plugin isn't calling gsf_init(), although I'm not really the libgsf Debian maintainer, just a bystander. Anyway, I still think this is the case. The gsf_init() call is surrounded by the #ifdef directive, but at least in the Debian environment gsf_init is a real function, not a preprocessor symbol, and the libextractor build system doesn't #define it either. I have verified that gsf_init() doesn't get called with gdb and a breakpoint; furthermore, a rebuild with the #ifdef/#endif directives removed doesn't crash. |
|
|
Fixed in SVN 5235 -- added a proper configure check for gsf_init. So if not calling gsf_init cause the problem, this should really fix it. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-06-28 14:13 | romainc | New Issue | |
| 2007-06-28 19:01 | Christian Grothoff | Note Added: 0003061 | |
| 2007-06-28 19:01 | Christian Grothoff | Status | new => feedback |
| 2007-06-29 00:06 | romainc | Note Added: 0003068 | |
| 2007-06-29 01:19 | Christian Grothoff | Note Added: 0003069 | |
| 2007-06-29 03:36 | romainc | Note Added: 0003071 | |
| 2007-06-29 22:59 | Christian Grothoff | Note Added: 0003072 | |
| 2007-07-03 10:04 | romainc | Note Added: 0003079 | |
| 2007-07-03 11:24 | Christian Grothoff | Note Added: 0003080 | |
| 2007-07-03 11:29 | Christian Grothoff | Note Edited: 0003080 | |
| 2007-07-04 00:39 | ntyni | Note Added: 0003082 | |
| 2007-07-04 17:31 | Christian Grothoff | Status | feedback => assigned |
| 2007-07-04 17:31 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2007-07-04 17:36 | Christian Grothoff | Status | assigned => resolved |
| 2007-07-04 17:36 | Christian Grothoff | Resolution | open => fixed |
| 2007-07-04 17:36 | Christian Grothoff | Note Added: 0003087 | |
| 2007-07-04 18:14 | Christian Grothoff | Status | resolved => closed |
