segfaults with newer libwww
|Target version:||Version 0.8.0|
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 :(
#1 Updated by vl about 3 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 3 years ago
- File disable_file_url.diff added
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 3 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?
#5 Updated by vl about 3 years ago
- Status changed from Assigned to Resolved
- % Done changed from 0 to 100
Applied in changeset r181.