Closed
Bug 388
Opened 26 years ago
Closed 24 years ago
Core dump when NavCenter is open and
Categories
(MozillaClassic Graveyard :: Aurora/RDF BE, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: waider, Assigned: guha)
Details
Created by Ronan Waide (waider@waider.ie) on Thursday, May 21, 1998 6:42:32 AM PDT
Additional Details :
Try this:
Sparc/Solaris 2.5.1
Fire up mozilla (current version)
Open NavCenter
Open a history view to the level of showing individual pages
In the main browser window, go to one of the displayed pages
If your history view is by site, you should get a crash
If your history view is by date, press back. *boom*.
As far as I can tell, the problem is due to some sort of
data mismatch between hist2rdf and ht. It's a bit hard to
track as there's a lot of jump-table stuff going on.
Stack trace:
#0 0xef2a3dc0 in strlen ()
#1 0xef2d613c in _strdup ()
#2 0x36f7f4 in resynchItem (node=0xc71180, token=0xb87820,
data=0x35642af9,
assertAction=1) at ht.c:1871
#3 0x36ac00 in htrdfNotifFunc (ns=0xbf9420, pdata=0xbfce80)
at ht.c:281
#4 0x369a48 in assertNotify (rdf=0xbf9220, not=0xbf9400,
u=0xc6eb60,
s=0xb87820, v=0x35642af9, type=2, tv=1, ds=0xb7ef40
"rdf:remoteStore")
at mcf.c:849
#5 0x36a0d0 in sendNotifications (rdf=0xbf9220, opType=1,
u=0xc6eb60,
s=0xb87820, v=0x35642af9, type=2, tv=1, ds=0xb7ef40
"rdf:remoteStore")
at mcf.c:944
#6 0x369f84 in sendNotifications2 (r=0xb81a80, opType=1,
u=0xc6eb60,
s=0xb87820, v=0x35642af9, type=2, tv=1) at mcf.c:926
#7 0x35ec00 in remoteStoreAdd (mcf=0xb81a80, u=0xc6eb60,
s=0xb87820,
v=0x35642af9, type=2, tv=1) at remstore.c:215
#8 0x38a500 in collateOneHist (r=0xb8a0c0, u=0xb84f40,
url=0xb8b300
"http://www.cognotec.com/~waider/emacs/index.html",
title=0xb8c2d0 "ehacks", lastAccessDate=895757049,
firstAccessDate=895662101, numAccesses=3, byDateFlag=0)
at hist2rdf.c:134
#9 0x38b4f8 in updateNewHistItem (key=0xefffc358,
data=0xefffc348)
at hist2rdf.c:359
#10 0x571218 in GH_UpdateURLTitle (pUrl=0xbcf600,
pszTitle=0xb8c240 "ehacks",
bFrameCell=0 '\000') at glhist.c:2211
#11 0x59194c in SHIST_SetTitleOfCurrentDoc (hist=0xb9140c,
title=0xbe4600 "ehacks") at shist.c:853
#12 0x114b00 in XFE_SetDocTitle (context=0xb91400,
title=0xbe4600 "ehacks")
at lay.c:2079
#13 0x423ba8 in lo_process_title_tag (context=0xb91400,
state=0xbcf200,
tag=0xb8c200) at laytags.c:824
#14 0x42bfb8 in lo_LayoutTag (context=0xb91400,
state=0xbcf200, tag=0xb8c200)
at laytags.c:4272
#15 0x3fedb4 in LO_ProcessTag (data_object=0xc71a00,
tag=0xb8c200, status=0)
at layout.c:4731
#16 0x449bcc in EDT_ProcessTag (data_object=0xc71a00,
tag=0xb8c200, status=0)
at editor.cpp:971
#17 0x535760 in PA_ParseBlock (stream=0xc74060,
block=0xb3b000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML
3.2//EN\">\n<HTML>\n<HEAD>\n <META
HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html;
charset=iso-8859-1\">\n <META NAME=\"GENERATOR\"
CONTENT=\"Mozilla/4.0b2 (Win95; I) "...,
block_len=4293) at pa_parse.c:1434
#18 0x53fff4 in net_AutoCharCodeConv (stream=0xc6dcc0,
s=0xb3b000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML
3.2//EN\">\n<HTML>\n<HEAD>\n <META
HTTP-EQUIV=\"Content-Type\" CONTENT=\"text/html;
charset=iso-8859-1\">\n <META NAME=\"GENERATOR\"
CONTENT=\"Mozilla/4.0b2 (Win95; I) "...,
l=4293) at net_junk.c:192
#19 0x336a2c in net_read_file_chunk (cur_entry=0xc5f980) at
mkfile.c:882
#20 0x337760 in net_ProcessFile (cur_entry=0xc5f980) at
mkfile.c:1233
#21 0x30d1b4 in NET_ProcessNet (ready_fd=0x0, fd_type=1) at
mkgeturl.c:3158
#22 0x31bffc in net_process_net_timer_callback (closure=0x0)
at mkselect.c:189
#23 0x1441ac in fe_do_timeout (p=0xc6df60, id=0xefffd93c) at
xfe.c:2921
#24 0xef5bec2c in XtAppProcessEvent ()
#25 0x11d7d0 in fe_EventLoop () at mozilla.c:1067
Updated by Ronan Waide (waider@waider.ie) on Thursday, May 21, 1998 8:31:23 AM PDT
Additional Details :
FIX: It appears that columns.c converts some RDF_INT_TYPE items
to HT_*_STRING types. This causes the above core. I've patched this out on my
copy of the source, but I'm not sure as yet if it breaks anything to do this.
Still, can't hurt to try. Here's the patch:
Index: modules/rdf/src/columns.c
===================================================================
RCS file: /cvsroot/mozilla/modules/rdf/src/columns.c,v
retrieving revision 3.2
diff -c -r3.2 columns.c
*** columns.c 1998/05/08 05:48:03 3.2
--- columns.c 1998/05/21 15:32:55
***************
*** 77,88 ****
{
if (u == gNavCenter->RDF_bookmarkAddDate ||
u == gWebData->RDF_lastVisitDate ||
! u == gWebData->RDF_lastModifiedDate)
{
- val = (void *)HT_COLUMN_DATE_STRING;
- }
- else if (u == gWebData->RDF_firstVisitDate)
- {
val = (void *)HT_COLUMN_DATE_INT;
}
else if (u == gWebData->RDF_size ||
--- 77,85 ----
{
if (u == gNavCenter->RDF_bookmarkAddDate ||
u == gWebData->RDF_lastVisitDate ||
! u == gWebData->RDF_lastModifiedDate ||
! u == gWebData->RDF_firstVisitDate)
{
val = (void *)HT_COLUMN_DATE_INT;
}
else if (u == gWebData->RDF_size ||
***************
*** 93,99 ****
else
{
/* default to string... XXX wrong thing to do */
! val = (void *)HT_COLUMN_STRING;
}
}
else if ((s == gNavCenter->RDF_ColumnWidth) &&
--- 90,96 ----
else
{
/* default to string... XXX wrong thing to do */
! val = (void *)HT_COLUMN_INT;
}
}
else if ((s == gNavCenter->RDF_ColumnWidth) &&
Updated by Robert Churchill (rjc@netscape.com) on Tuesday, May 26, 1998 6:13:32 PM PDT
Additional Details :
Don't apply the fix from Ronan Waide... its not the appropriate fix.
There are really three (sigh, yes, 3) types of dates in RDF:
Numeric 32-bit Integer representation of dates (such as 123456789)
String representations of 32-bit Integer dates (such as "123456789")
Strings dates (such as "May 26, 1998 12:02 PM")
column.c wasn't "converting" RDF_INT_TYPE to a string. When asked "What kind of
type is X?" (where X was one of the three types above) it would try and respond
with a number (always an integer) that was its guess.
Unfortunately, different sections of code in various spots in RDF would mark
things differently... for example, Bookmark code would say that the
RDF_FirstVisitDate entry was a "Numeric Date String" while History code would say
that the RDF_FirstVisitDate entry was a "Numeric Date" (not a String).
So, that's bad. The "right thing" to do, which I've just done, is to have every
section of code in RDF use the same representation of dates... I chose STRINGs.
Thanks for pointing this problem out!
Robert
rjc@netscape.com
Updated by Robert Churchill (rjc@netscape.com) on Tuesday, May 26, 1998 6:14:01 PM PDT
Additional Details :
Comment 1•24 years ago
|
||
mid-air collision ? / bugzilla cleanup
Reopening (current State: resolved and no resolution)
Status: RESOLVED → REOPENED
Summary: Core dump when NavCenter is open and → Core dump when NavCenter is open and
Comment 2•24 years ago
|
||
marking fixed (not clear)
Status: REOPENED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•