NetSurf question

Daniel Taylor dannytaylor at visi.com
Fri Jan 4 17:07:22 GMT 2008


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 <rjek at netsurf-browser.org> 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.
> 
> 
> 
> 



More information about the netsurf-dev mailing list