hlcache_handle_get_content assert is need ?

John-Mark Bell jmb at netsurf-browser.org
Tue Jun 29 21:53:22 BST 2010


On Tue, 2010-06-29 at 21:47 +0200, Bernd Roesch wrote:
> Hello John-Mark
> 
> On 28.06.10, you wrote:
> 
> > On Mon, 2010-06-28 at 10:53 +0200, Bernd Roesch wrote:
> >> Hi, 
> >> 
> >> A user report when he log in to www.netmail.nl (it use https but the start page work) to get
> >> mails
> >> 
> >> he get this error
> >> 
> >> content/hlcache.c:257: failed assertion `handle != NULL'
> >> Abort trap - Netsurf 
> > 
> > You'll have to provide a full backtrace before anyone can debug this.
> 
> thats hard, because its not my computer.

Can you ask the user who reported it?

> But the problem of the arstechnica.com load i get is in the same Function but little diffrent,  it
> happen always on my system when debug too.netsurf without cache have not the problem.

I still have not seen any logging output from the crashes you've
described in the past. Please enable verbose debug in both fetch.c and
llcache.c. Also enable verbose curl debug (set the suppress_curl_debug
setting in the Choices file to 0).

It appears that what follows is a description of a completely different
issue, to the original report of an assertion failing. In future, please
ensure that you start a new thread for each issue, otherwise it's just
confusing.

> here it happen that the structure 
> 
> struct hlcache_handle {
>     hlcache_entry *entry;       /**< Pointer to cache entry */
> 
>     hlcache_handle_callback cb; /**< Client callback */
>     void *pw;           /**< Client data */
> };
> 
> contain 0 as entry value.

Well it will, until sufficient data has been fetched to actually create
the entry. All the cache handles are indirection objects, for precisely
this purpose.

> I also do not notice what code do the entry value set.

That field is populated about half way through hlcache_find_content.

> I find this notice in source, so maybe its possible that there is some timing issue

Timing issues are the cause of 95% of crashes in the caching layer: it's
the result of synchronising an inherently asynchronous process.

> the code that want access the cache event is this but 
> 
> sheet = s-> data.css.sheet;
> 
> do crap because
> 
> s = 0 

I'm sorry?

> In html.c here the cache access is do.
> 
> void html_finish_conversion(struct content *c)
> {
 
[...]

>     /* Add sheets to it */
>     for (i = STYLESHEET_BASE; i != c->data.html.stylesheet_count; i++) {
>         const struct html_stylesheet *hsheet =
>                 &c->data.html.stylesheets[i];
>         css_stylesheet *sheet;
>         css_origin origin = CSS_ORIGIN_AUTHOR;
> 
>         if (i < STYLESHEET_START)
>             origin = CSS_ORIGIN_UA;
> 
>         if (hsheet->type == HTML_STYLESHEET_EXTERNAL &&
>                 hsheet->data.external != NULL) {
>             struct content *s = hlcache_handle_get_content(
>                     hsheet->data.external);
> 
> ------>            sheet = s-> data.css.sheet;

There should never be a handle without an associated content at this
point: the completion of the HTML conversion is conditional on all
stylesheet fetches being completed. Failed stylesheet fetches will
result in hsheet->data.external being NULL. Again, I need the verbose
log output to see what's going on here.

> ---------------------------------
> 
> but the real fail come only later in the func xml_to_box
> 
> and in box_construct.c
> 
> partial = nscss_get_style(c, n, CSS_PSEUDO_ELEMENT_NONE,
>                   CSS_MEDIA_SCREEN, inline_style,
>                   box_style_alloc, NULL);
> 
> partial get 0

What? Is this another completely unrelated issue? In what circumstances
does it happen? I'm really not sure that you're actually telling us
everything. Are you working with a modified source tree?

> libcurl that is used is 7.21.0

I don't see the relevance of this.


J.




More information about the netsurf-dev mailing list