Bug 16099 – Crash in CURL for empty POST

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Seo Sanghyeon]

SVN r27981. ./build-webkit --gtk.

Open the URL with GtkLauncher. It immeidately crashes inside CURL. The URL posts an empty form.

This prevents use of http://mail.daum.net/, the #1 webmail site in Korea.

[Alp Toker]

Created attachment 17586 [details]
Fix crasher

I haven't checked to see if there are other instances of this bug in ResourceHandleManager or whether there is a better place to do this check yet. Does it do the trick for you?

[Alp Toker]

Created attachment 17587 [details]
Avoid deadlock too

[Seo Sanghyeon]

I still get the crash after applying the patch.

[Luca Bruno]

Created attachment 17787 [details]
patch

Can you try this one?
Alp, the main problem is that the httpBody is NULL.
The patch checks that in setupPOST like yours, but is it right that httpBody is being set to NULL somewhere?

[Alp Toker]

Comment on attachment 17787 [details]
patch

This page seems to just hang the browser now. The patch doesn't fix the hang. Probably due to recent fixes.

[Luca Bruno]

Doesn't crash to me after fixing job cancellation. Can you all check please?

[Seo Sanghyeon]

SVN r29020. ./autogen.sh; make. No patch.

URL now hangs as described by Alp in #5.

[Luca Bruno]

Did you do make install and ran GtkLauncher without using the run-launcher right?

[Seo Sanghyeon]

Of course.

[Luca Bruno]

Can you please paste a traceback here?

[Seo Sanghyeon]

How does one produce a traceback of the hanged program?

[Luca Bruno]

I know i'm boring you :) but really i'm both trying to reproduce the bug and getting informations from you.

Please ensure you're using the right library. You switched from qmake to autotools this may lead to using mismatched libraries. For example, retry using qmake with svn HEAD. Remove all libWebKit* from your system.

Can you press ctrl+c inside gdb when it hangs?

Maybe the problem is on font rendering? Are you able to open other korean web sites?

[Seo Sanghyeon]

> Are you able to open other Korean web sites?

Yes, Korean web sites render fine.

> Please ensure you're using the right library.

$ ldd Programs/.libs/GtkLauncher | grep WebKit
libWebKitGtk.so.1 => /opt/webkit/lib/libWebKitGtk.so.1

I checked the modification time of the above file.

> Can you press ctrl+c inside gdb when it hangs?

Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb598d6c0 (LWP 26137)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb615fb5b in read () from /lib/i686/cmov/libc.so.6
#2  0xb60fdd49 in ?? () from /lib/i686/cmov/libc.so.6
#3  0xb60fff58 in _IO_sgetn () from /lib/i686/cmov/libc.so.6
#4  0xb60f3f5e in fread () from /lib/i686/cmov/libc.so.6
#5  0xb79db3da in ?? () from /usr/lib/libcurl.so.4
(much more ??s)

[Luca Bruno]

What are the first 2-3 functions of WebKit in the traceback? You stopped to libcurl...

Which version of libcurl you have? Here 7.17.1

[Seo Sanghyeon]

No function of WebKit in the traceback.
libcurl is Debian package libcurl3 7.17.1-1. The same version you have.

[Luca Bruno]

Without the patch doesn't hang to me. Maybe you have the patch still applied.

Can you please revert the patch, update to HEAD and ensure there're no conflicts in WebCore/platform/network/curl/ReasourceHandleManager.cpp, then retry?

[Seo Sanghyeon]

I don't have any patch applied. Please don't treat me as an idiot.

Apparently I'm not the only person who can reproduce this bug. I hope others will chime in.

[Alp Toker]

Seo, I think Luca was just going through some basic diagnostic steps.

I've reproduced the hang with a TOT build. There is probably not much more to be speculated on this bug until it's traced using gdb. Could turn out to be a re-entrancy issue or anything.

Another option is to experiment with new http backends -- they're not that hard to write and the current curl http backend is a bit messy.

[Luca Bruno]

Created attachment 18189 [details]
post empty data

Sorry Seo, i don't think you are an idiot really.

Well i got finally this hang with svn HEAD.

The patch is very simple, i just remove a condition which avoids empty POST from being transmitted. This seems to fix the problem.
If that's the issue, I wonder the purpose of that condition and if this patch could bring a regression.

Seo, can you try with this patch? Thanks.

[Luca Bruno]

Created attachment 18190 [details]
add changelog entry

[Alp Toker]

Comment on attachment 18190 [details]
add changelog entry

r=me

The old check was clearly wrong.

[Alp Toker]

Landed in r29037.