I was kind of expecting something to that effect. I'll look into recompiling libc, then.
Thanks for all of your help and patience! Daniel Taylor On Fri, 04 Jan 2008 22:49:17 +0000 Rob Kendrick <[EMAIL PROTECTED]> wrote: > > 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. > > > >
