Bug 28947 - ASSERT executing the webhistory unittest in a debug build
Summary: ASSERT executing the webhistory unittest in a debug build
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-03 07:27 PDT by Xan Lopez
Modified: 2009-10-06 04:57 PDT (History)
1 user (show)

See Also:


Attachments
Patch fixing the problem (1.51 KB, patch)
2009-10-06 01:44 PDT, Alejandro G. Castro
no flags Details | Formatted Diff | Diff
Fixed Changelog style (1.64 KB, patch)
2009-10-06 01:53 PDT, Alejandro G. Castro
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2009-09-03 07:27:02 PDT
/webkit/webhistoryitem/get_data: ASSERTION FAILED: isMainThread()
(../../WebCore/platform/text/TextEncodingRegistry.cpp:176 void WebCore::buildBaseTextCodecMaps())

Program received signal SIGSEGV, Segmentation fault.
0x014d7e48 in buildBaseTextCodecMaps () at ../../WebCore/platform/text/TextEncodingRegistry.cpp:176
176	    ASSERT(isMainThread());
Current language:  auto; currently c++
Missing separate debuginfos, use: debuginfo-install libgcc-4.4.0-0.31.i586 libstdc++-4.4.0-0.31.i586 libxml2-2.7.3-2.fc10.i386
(gdb) bt
#0  0x014d7e48 in buildBaseTextCodecMaps () at ../../WebCore/platform/text/TextEncodingRegistry.cpp:176
#1  0x014d811f in WebCore::atomicCanonicalTextEncodingName (name=0x1d5eb8c "UTF-8") at ../../WebCore/platform/text/TextEncodingRegistry.cpp:241
#2  0x014d57ff in TextEncoding (this=0x29d8c00, name=0x1d5eb8c "UTF-8") at ../../WebCore/platform/text/TextEncoding.cpp:61
#3  0x014d6402 in WebCore::UTF8Encoding () at ../../WebCore/platform/text/TextEncoding.cpp:266
#4  0x014689dc in KURL (this=0xbfffeb94, base=@0xbfffebd0, relative=@0xbfffebcc) at ../../WebCore/platform/KURL.cpp:319
#5  0x00ec783a in webkit_web_history_item_new_with_data (uri=0x8048709 "http://example.com/", title=0x8048700 "Example1")
    at ../../WebKit/gtk/webkit/webkitwebhistoryitem.cpp:300
#6  0x0804824e in web_history_item_fixture_setup (fixture=0x804d928, data=0x0) at ../../WebKit/gtk/tests/testwebhistoryitem.c:33
#7  0x00c79077 in test_case_run (tc=0x804c808) at gtestutils.c:1129
#8  0x00c7934c in g_test_run_suite_internal (suite=0x8076540, path=0xcbb04c "") at gtestutils.c:1179
#9  0x00c79401 in g_test_run_suite_internal (suite=0x8076530, path=0xcbb04c "") at gtestutils.c:1189
#10 0x00c79401 in g_test_run_suite_internal (suite=0x8076510, path=0xcbb04c "") at gtestutils.c:1189
#11 0x00c79588 in IA__g_test_run_suite (suite=0x8076510) at gtestutils.c:1230
#12 0x00c7876c in IA__g_test_run () at gtestutils.c:862
#13 0x08048623 in main (argc=1, argv=0xbfffef14) at ../../WebKit/gtk/tests/testwebhistoryitem.c:71
(gdb)
Comment 1 Xan Lopez 2009-09-03 07:29:28 PDT
This was touched recently in r47911, which claimed to be also fixing a possible ASSERT in debug builds. Mmmm :)
Comment 2 Alejandro G. Castro 2009-10-06 01:44:00 PDT
Created attachment 40701 [details]
Patch fixing the problem

The problem was caused because webkit_init was not called before the instantiation of a KURL. Apparently webkit_init is being called in the class_init but it is not enough in these cases. If we want a more general solution we can check all the places that could cause a problem like this or comment that webkit_init should be called by the programs before doing anything (but this would mean adding the function to the API if it is not). Anyway we have to consider that if someone uses webkit library and tries to create a KURL is going to have problems if they do not call webkit_init in advance calling other API functions.
Comment 3 Xan Lopez 2009-10-06 01:47:42 PDT
(In reply to comment #2)
> Created an attachment (id=40701) [details]
> Patch fixing the problem
> 
> The problem was caused because webkit_init was not called before the
> instantiation of a KURL. Apparently webkit_init is being called in the
> class_init but it is not enough in these cases. If we want a more general
> solution we can check all the places that could cause a problem like this or
> comment that webkit_init should be called by the programs before doing anything
> (but this would mean adding the function to the API if it is not). Anyway we
> have to consider that if someone uses webkit library and tries to create a KURL
> is going to have problems if they do not call webkit_init in advance calling
> other API functions.

Keep in mind that KURL and everything else in WebCore is not public API, so that is not a problem. The problem is that we might have lots of other functions where calls to WebCore are made before any class_init is called, which as shown in this test can cause problems.
Comment 4 Alejandro G. Castro 2009-10-06 01:53:52 PDT
Created attachment 40702 [details]
Fixed Changelog style

Sorry about that :)
Comment 5 Xan Lopez 2009-10-06 01:56:48 PDT
Comment on attachment 40702 [details]
Fixed Changelog style

r=me, thanks!
Comment 6 WebKit Commit Bot 2009-10-06 04:57:29 PDT
Comment on attachment 40702 [details]
Fixed Changelog style

Clearing flags on attachment: 40702

Committed r49172: <http://trac.webkit.org/changeset/49172>
Comment 7 WebKit Commit Bot 2009-10-06 04:57:32 PDT
All reviewed patches have been landed.  Closing bug.