On Fri, 2008-01-04 at 15:54 +0000, Daniel Taylor wrote: > Attached is a copy and paste of the output from gdb, running nsgtk directly.
> Program received signal SIGABRT, Aborted. > 0x40a62094 in kill () from /lib/libc.so.6 > (gdb) bt > #0 0x40a62094 in kill () from /lib/libc.so.6 > #1 0x40a22ae4 in pthread_kill () from /lib/libpthread.so.0 > #2 0x40a230e0 in raise () from /lib/libpthread.so.0 > #3 0x40a634fc in abort () from /lib/libc.so.6 > #4 0x40adf6e0 in fnmatch () from /lib/libc.so.6 > #5 0x40ade11c in fnmatch () from /lib/libc.so.6 > #6 0x40ae77b8 in re_search () from /lib/libc.so.6 > #7 0x40ae7eb8 in regexec () from /lib/libc.so.6 > #8 0x00072be4 in url_normalize (url=0xb53f0 > "http://netsurf-browser.org/";, result=0xbeb8f828) at utils/url.c:136 > #9 0x00087e38 in browser_window_go_post (bw=0x264bf0, url=0xb53f0 "http://netsurf-browser.org/";, post_urlenc=0x0, > post_multipart=0x0, > history_add=true, referer=0x0, download=false, verifiable=true, > parent_url=0x0) > at desktop/browser.c:290 > #10 0x00087c6c in browser_window_go (bw=0x264bf0, > url=0xb53f0 "http://netsurf-browser.org/";, referer=0x0, > history_add=true) > at desktop/browser.c:217 > #11 0x00087ac0 in browser_window_create (url=0xb53f0 > "http://netsurf-browser.org/";, > clone=0x0, referer=0x0, history_add=true) at desktop/browser.c:165 >#12 0x0009ab80 in gui_init2 (argc=1, argv=0xbeb8fac4) at > gtk/gtk_gui.c:283 > #13 0x0009157c in netsurf_init (argc=1, argv=0xbeb8fac4) at > desktop/netsurf.c:111 > #14 0x00091308 in main (argc=1, argv=0xbeb8fac4) at > desktop/netsurf.c:60 Right. The code we use to parse URLs uses the libc's regular expressions code. It looks as if it's somewhere within the C library's regexec() function is causing the abort. I have two theories: 1) The Zaurus's OS may use a libc other than glibc, and thus its regular expression implementation may be lacking, and we're using features it does not support, or tickle a bug. This would be a limitation of the Zaurus's libc, and past shipping our own regex library, or reimplementing the URL parsing without regexps, there isn't much we could do to work around it. 2) Something deeply insane is happening, given regexec() is calling fnmatch(), which is a function to do shell-style filename glob matching and has nothing to do with regular expressions what-so-ever. If regexec() is calling that, it may be by accident, and thus passing nonsense to it, causing fnmatch() to abort. This would be a bug in the Zaurus's libc, and there wouldn't be much we could do to work around it. It could be both. Or something I've not thought of. I've run out of the ability to debug this via email, essentially. Unless somebody else has an epiphany about what on earth is causing 2, or can confirm 1, you'll on your own debugging it unless you provide one of the developers with hardware to test on :-/ B.
