Summary: | media-gfx/gthumb-3.0.0 - segmentation fault in strlen(""), called from g_str_has_prefix at gstrfuncs.c:2774 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | toolchain |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Juergen Rose
2012-10-22 09:57:35 UTC
If I emerge gthumb without the raw USE flag and start gthumb directly (not through gdb), linux crashes with general protection fault Also if I run gthumb through gdb linux sometimes crashes with general protection fault. I just commited 3.0.2 yesterday, could you give it a try ? Hum actually I didn't commit it because I had a general protection fault as well. I guess there is something fishy with gthumb. Hi Gilles, inpite of two 'emerge --sync' since yesterday, there is not yet any gthumb-3.0.2 here. But beside of Segfaults and General protection faults I see now also kernel paging request Oops. I have the feeling that the error is not in gthumb but in the nouveau driver. At least I see the errors only at two systems with a NVIDIA card and with xf86-video-nouveau-1.0.2 driver. At a third system with a ATI card and the xf86-video-ati-6.14.6-r1 driver gthumb works without any problems. (In reply to comment #0) Good backtrace! In glib-2.32.4, g_str_has_prefix() has the following implementations: gboolean g_str_has_prefix (const gchar *str, const gchar *prefix) { int str_len; int prefix_len; g_return_val_if_fail (str != NULL, FALSE); g_return_val_if_fail (prefix != NULL, FALSE); str_len = strlen (str); prefix_len = strlen (prefix); if (str_len < prefix_len) return FALSE; return strncmp (str, prefix, prefix_len) == 0; } And gstrfuncs.c:2774 is this line: "str_len = strlen (str);" In your case, str was 0x7fffc809c000, which was pointer to "", a perfectly valid string. So strlen(str) should have returned 0; instead, it crashed. Therefore, I see two possibilities: (1) a bug is in strlen() itself meaning in sys-libs/glibc. @toolchain, is that possible? I believe that glibc uses some tricky assembly code to speed up strlen()... (2) threading bug in gthumb that caused str to be freed just before strlen() was done with it. (In reply to comment #6) it's possible that strlen has a bug in the optimized version. that assembly code does a lot of tricky stuff to be fast and compare as many bytes as possible. you could try this test code: #include <assert.h> #include <stdio.h> #include <string.h> #include <unistd.h> #include <sys/mman.h> int main() { int page_size = getpagesize(); printf("page_size = %#x\n", page_size); char *buf = mmap(NULL, 2 * page_size, PROT_READ | PROT_WRITE, \ MAP_PRIVATE | MAP_ANON, -1, 0); assert(buf != MAP_FAILED); assert(mprotect(buf + page_size, page_size, PROT_NONE) == 0); return strlen(buf + page_size - 1); } just: gcc test.c && ./a.out Still the case with 3.2.3? Please try out latest gthumb, 3.2.3 |