Bug #892

segfaults with newer libwww

Added by ratmice about 5 years ago. Updated about 5 years ago.

Status:Closed Start date:05/13/2010
Priority:Normal Due date:
Assignee:vl % Done:

100%

Category:-
Target version:Version 0.8.0

Description

libwww under linux is segfaulting
I imagine most people on windows are using the externals libwww which probably doesn't have the issue,
since i believe it has memory leaks/leaks file descriptors?.

the first issue is a bug in libwww, unfortunately after fixing the bug in libwww,
we end up segfaulting in a different way, because
libwww_nel_stream.cpp is abusing the libwww api by passing a CIFile* fp, instead of a FILE , to HTChannel_new,
with the leaking of file descriptors fixed in libwww, this tries to close the FILE * (actually a CIFile
), which causes a new issue,
this one caused by client.
and all of the libwww_nel_stream.cpp callbacks are assuming CIFile * :/

I imagine that the leaking of file descriptors is what caused all this in the first place,

anyhow, if the plan is to remove libwww usage and replace it with curl + some parser,
it is probably easier to do that than to fix the libwww code that is there.

this segfault only seems to affect the usage of file:/ URL's

so a possible workaround is to temporarily exit early if lookupLocalFile returns true at group_html.cpp:2682
and slap a comment on there that this is a temporary non-solution.
another non-solution is to give bad file urls e.g. "file://" + "stopsegfaultingdangit" + path
this causes the whole thing to bail out before we get into the file descriptor madness since the file doesn't exist...

Anyways I sorta think any more effort on this is better spent towards replacing it than fixing it :(

disable_file_url.diff (1004 Bytes) Magnifier ratmice, 05/13/2010 08:30 pm

History

#1 Updated by vl about 5 years ago

I agree to comment the file:// use until we move to libcurl.

libwww is a pain and not maintained anymore so since we already use libcurl for new dev, it would be great to completely remove the use of this lib.

#2 Updated by ratmice about 5 years ago

here is a patch for that,

with this patch, i can now stay in game for quite a while (until i quit at least),
so for me at least the engine is somewhat stable YMMV ;)

#3 Updated by vl about 5 years ago

I think the patch is wrong, the line should be:

if (isLocal || ((_LibWWW->Anchor = HTAnchor_findAddress(uri)) == NULL))

because in your case, if the url is local, it executes the code and we want the opposite no?

#4 Updated by vl about 5 years ago

  • Status changed from New to Assigned
  • Assignee set to vl

#5 Updated by vl about 5 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Applied in changeset r181.

#6 Updated by vl about 5 years ago

  • Target version set to Version 0.8.0

#7 Updated by vl about 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF