Solaris 2.6, gcc 2.7.2.3, purify. GTK 1.2. Pull from around 2pm PST on Friday, March 12, 1999. UMR: Uninitialized memory read: * This is occurring while in: TextFrame::GetPosition(nsIPresContext&,nsIRenderingContext*,nsGUIEvent*,nsIFrame *,unsigned int&,int&) [nsTextFrame.cpp:1701] nsFrame::HandleDrag(nsIPresContext&,nsGUIEvent*,nsEventStatus&) [nsFrame.cpp:757] nsFrame::HandleEvent(nsIPresContext&,nsGUIEvent*,nsEventStatus&) [nsFrame.cpp:679] PresShell::HandleEvent(nsIView*,nsGUIEvent*,nsEventStatus&) [nsPresShell.cpp:1930] nsView::HandleEvent(nsGUIEvent*,unsigned int,nsEventStatus&) [nsView.cpp:824] nsView::HandleEvent(nsGUIEvent*,unsigned int,nsEventStatus&) [nsView.cpp:806] nsView::HandleEvent(nsGUIEvent*,unsigned int,nsEventStatus&) [nsView.cpp:806] nsScrollingView::HandleEvent(nsGUIEvent*,unsigned int,nsEventStatus&) [nsScrollingView.cpp:874] nsView::HandleEvent(nsGUIEvent*,unsigned int,nsEventStatus&) [nsView.cpp:806] nsViewManager::DispatchEvent(nsGUIEvent*,nsEventStatus&) [nsViewManager.cpp:1707] HandleEvent(nsGUIEvent*) [nsView.cpp:63] nsWidget::DispatchEvent(nsGUIEvent*,nsEventStatus&) [nsWidget.cpp:815] nsWidget::DispatchWindowEvent(nsGUIEvent*) [nsWidget.cpp:775] nsWidget::DispatchMouseEvent(nsMouseEvent&) [nsWidget.cpp:841] handle_motion_notify_event(_GtkWidget*,_GdkEventMotion*,void*) [nsGtkEventHandler.cpp:604] gtk_marshal_BOOL__POINTER [gtkmarshal.c:32] gtk_handlers_run [gtksignal.c:1909] gtk_signal_real_emit [gtksignal.c:1469] gtk_signal_emit [gtksignal.c:552] gtk_widget_event [gtkwidget.c:2784] gtk_propagate_event [gtkmain.c:1295] gtk_main_do_event [gtkmain.c:752] gdk_event_dispatch [gdkevents.c:2086] g_main_dispatch [gmain.c:647] g_main_iterate [gmain.c:854] g_main_run [gmain.c:912] gtk_main [gtkmain.c:475] nsAppShell::Run() [nsAppShell.cpp:152] nsNativeViewerApp::Run() [nsGTKMain.cpp:42] main [nsGTKMain.cpp:97] * Reading 4 bytes from 0xefffcccc on the stack. * Address 0xefffcccc is local variable "textWidth" in function TextFrame::GetPosition(nsIPresContext&,nsIRenderingContext*,nsGUIEvent*,nsIFrame *,unsigned int&,int&).

Changed to M3

i wish I had more info like which variable ect. I will try to run purify and check.

check out the info at the tail end of the report from purify. 'textWidth' in TextFrame::GetPosition()

ahh eeeexcellent. gracias.

Moving to M4

Mike, I'm seeing crashes in this same area, still, while drag-selecting over the PRE text on Sample 1.

the opt build isn't helpful as far as providing debug info (duh) so I can't confirm it's the same thing but yes the Linux builds (Mar24) will crash. That is if you try to drag-select on resource:/res/samples/test1.html I wasn't sure if that was what simon was implying or if he meant on another platform.

This does happen on that URL when dragging in that area .. and is the first in a series of UMRs that I'm about to report that then causes the core dump (an assertion gets hit).

This, along with bugs #4254 and #4255 look to be the cause of the coredump (which is because it is hitting an assert). Enjoy.

I think this will turn out to be a dup of #4145.

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

not a real problem. i have a fix but not going in now. when tree opens for m5 i will commit the change

should be fixed now thanks

so it doesn't crash anymore but that wasn't *truly* the problem - just a symptom. Bruce, if you could do the honors and double- check this I'd be real grateful. You can either mark it verified (with a build and date) or just 'say the word' and I'll do so.

...not to imply that it's not fixed like Mike says, just for QA purposes because as we've already discussed, I can't truly verify these. Sorry all for the extra spam.

Per a request from Selection and Search component eng (mjudge) and qa (elig), moving all "Selection and Search" bugs to new "Selection" component. Original "Selection and Search" component will be retired.