Bug 120246 – REGRESSION(r154498): Crashes on EFL, GTK, Qt on release configurations

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Zan Dobersek]

Crashes are occurring when running JSC and layout tests on the EFL, GTK and Qt ports after r154498.
http://trac.webkit.org/changeset/154498

http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release/builds/40093
http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Release%20WK1/builds/1428
http://build.webkit.org/builders/Qt%20Linux%20Release/builds/62368

The crashes are occurring only on release builds due to the TcMalloc use being enforced under that configuration. The crashes disappear if ENABLE_GLOBAL_FASTMALLOC_NEW is defined to 1, or if the system malloc is also enforced for the release configuration. All the affected ports set this define to 0 (and so does the AppleWin port, but it doesn't currently build so I can't confirm crashes there).

Disabling the optimizations shows that the crash occurs in WTF::deleteOwnedPtr<WTF::CompressedVector<JSC::ExpressionRangeInfo> >(WTF::CompressedVector<JSC::ExpressionRangeInfo>*), due to the `delete ptr` call. The crash occurs because the pointer was allocated through fastMalloc (in GenericCompressedData::create), but is being freed as if it were allocated by the system malloc on the affected systems. fastFree() should be used instead.

[Zan Dobersek]

Created attachment 209536 [details]
Possible fix

Instead of calling m_compressedData.clear(), its leaked pointer is fastFree()d.

Not putting this up for a review yet because I'm not sure of the validity of the approach.

[Oliver Hunt]

Oh, i'm a muppet -- what happens if GenericCompreesedData gets the WTF_MAKE_FAST_ALLOC or whatever it is macro?

[Oliver Hunt]

Created attachment 209553 [details]
Patch

[EFL EWS Bot]

Comment on attachment 209553 [details]
Patch

Attachment 209553 [details] did not pass efl-wk2-ews (efl-wk2):
Output: http://webkit-queues.appspot.com/results/1543735

[Oliver Hunt]

Committed r154552: <http://trac.webkit.org/changeset/154552>