Goto the above url and click on the talkback graphics...BOOM... Core Dump in laysel.c Here is a stack trace, The problem is the begin is NULL and being dereferenced. There was no selection when i went to the above url. #0 0x403f891d in lo_HitLine (context=0x861fe00, state=0x862de00, x=393, y=15, requireCaret=1 '\001', result=0xbfffd2c4) at laysel.c:4487 ---Type <return> to continue, or q <return> to quit--- 4487 if ( begin->type != LO_LINEFEED && end->type == LO_LINEFEED ) { (gdb) bt #0 0x403f891d in lo_HitLine (context=0x861fe00, state=0x862de00, x=393, y=15, requireCaret=1 '\001', result=0xbfffd2c4) at laysel.c:4487 #1 0x403f9236 in LO_Hit (context=0x861fe00, x=393, y=15, requireCaret=1 '\001', result=0xbfffd2c4, layer=0x8668b00) at laysel.c:4941 #2 0x403f93de in LO_Click (context=0x861fe00, x=393, y=535, requireCaret=1 '\001', layer=0x8668b00) at laysel.c:5009 #3 0x403f2fab in LO_StartSelection (context=0x861fe00, x=393, y=535, layer=0x8668b00) at laysel.c:426 #4 0x80baefd in fe_arm_link_action_for_layer (context=0x861fe00, layer=0x8668b00, layer_event=0x854e600) at lay.c:3461 #5 0x80d8fe1 in FE_HandleLayerEvent (context=0x861fe00, layer=0x8668b00, layer_event=0x854e600) at xfe.c:3280 #6 0x403dc138 in lo_html_event_callback (pContext=0x861fe00, pEle=0x86a99e8, event=1, pObj=0x826e020, status=EVENT_OK) at laylayer.c:305 #7 0x406b5bce in et_HandleEvent_JsEventAck (e=0x8652500) at et_moz.c:1311 #8 0x407c612f in PL_HandleEvent (self=0x8652500) at plevent.c:395 #9 0x407c6049 in PL_ProcessPendingEvents (self=0x8271280) at plevent.c:357 #10 0x80bfc18 in fe_event_processor_callback (closure=0x0, fd=0x8495134, id=0xbfffd428) at mozilla.c:1812 #11 0x408e093d in XtAppProcessEvent () #12 0x80bee2e in fe_EventLoop () at mozilla.c:1141 #13 0x80c20d1 in main (argc=1, argv=0xbfffeca4) at mozilla.c:3421 (gdb) (gdb) p begin $2 = (LO_Element *) 0x0

I just verified that this happens on nt as well.

Charley recently checked in a bunch of selection code changes. This could potentially be caused by them. Charley, can you please be the first line of investigation for this bug? Please re-assign the bug to yourself if you agree. Also, once you've looked at it, please don't hesitate to re-assign it to back to me if the problem is unrelated to your changes. Thanks.

This problem isn't in any of the code I touched, but I did investigate it. This is happening in on mouse down when starting a selection - here's an edited stack: lo_HitLine(... LO_Hit(... LO_Click(... LO_StartSelection(... Here's the relevant code in lo_HitLine: /* * Search from current line backwards to find something to edit. */ for ( line = lo_PointToLine(context, state, x, y); line >= 0; line-- ) { LO_Element* begin; LO_Element* end; LO_Element* tptr; lo_GetLineEnds(context, state, line, & begin, & end); /* lo_GetLineEnds returns the start of the next line for 'end' */ if ( end ) { end = end->lo_any.prev; } else { /* Last line. We know that the last line only has one element. */ end = begin; } /****** CRASH IF begin == 0 ***********/ /* How can this be? */ if( begin == 0 ) continue; /****** END OF ADDED CODE ***********/ /* Except for cases where the entire line is a line feed, don't select the end line-feed. */ if ( begin->type != LO_LINEFEED && end->type == LO_LINEFEED ) { end = end->lo_any.prev; } ... The added code show aboveprevents the crash, but the problem is deeper: Why is it failing to find a begin element? With my "fix", it doesn't crash, but you can't select any text in the page (everything is inside a table.) Leaving assigned to nisheeth for further investigation.

Charley checked in his temp fix today to avoid the crash. I'll take a look at why "begin" is being returned as NULL. Changing platform to All.

Putting on ss: radar.

*** Bug 1014 has been marked as a duplicate of this bug. ***

doesn't crash on win95 (haven't checked on linux), so not a stop ship for developer release. Will leave bug open since it looks like it's still under investigation, but removing the ss:

This bug existed in the old layout engine. Marking wontfix because the old layout engine is dead. NGLayout does not exhibit this bug.

Marking Verified as a Won't Fix.

Sorry for the spam. I needed to find a really old bug so that I could test out line wrapping on Win32 to see what would happen. You see, in yesterday's build, it wouldn't put the line-wraps into to the bug when I wrote something really, really, long a droll like this. Okay, that should be long enough. This ends your regularly scheduled programming.

<spam> Testing some things on a really really old and deprecated bug. Please ignore. </spam>

Status CLOSED is deprecated as per bug 169885

Re-resolving

verifying former CLOSED bug

see comment #12