Bug 120246 - REGRESSION(r154498): Crashes on EFL, GTK, Qt on release configurations
Summary: REGRESSION(r154498): Crashes on EFL, GTK, Qt on release configurations
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Oliver Hunt
URL:
Keywords:
Depends on:
Blocks: 79668 120143
  Show dependency treegraph
 
Reported: 2013-08-24 02:35 PDT by Zan Dobersek
Modified: 2013-08-24 13:06 PDT (History)
12 users (show)

See Also:


Attachments
Possible fix (571 bytes, patch)
2013-08-24 02:39 PDT, Zan Dobersek
no flags Details | Formatted Diff | Diff
Patch (1.23 KB, patch)
2013-08-24 13:00 PDT, Oliver Hunt
koivisto: review+
eflews.bot: commit-queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zan Dobersek 2013-08-24 02:35:44 PDT
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.
Comment 1 Zan Dobersek 2013-08-24 02:39:31 PDT
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.
Comment 2 Oliver Hunt 2013-08-24 12:53:10 PDT
Oh, i'm a muppet -- what happens if GenericCompreesedData gets the WTF_MAKE_FAST_ALLOC or whatever it is macro?
Comment 3 Oliver Hunt 2013-08-24 13:00:25 PDT
Created attachment 209553 [details]
Patch
Comment 4 EFL EWS Bot 2013-08-24 13:05:37 PDT
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
Comment 5 Oliver Hunt 2013-08-24 13:06:17 PDT
Committed r154552: <http://trac.webkit.org/changeset/154552>