If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

UMR: TextFrame::GetPosition()

VERIFIED FIXED in M5

Status

()

Core
Selection
P3
normal
VERIFIED FIXED
19 years ago
19 years ago

People

(Reporter: Bruce Mitchener, Assigned: mjudge)

Tracking

Trunk
Sun
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: just waiting on reporter/developer verification, URL)

(Reporter)

Description

19 years ago
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&).

Updated

19 years ago
Target Milestone: M3

Comment 1

19 years ago
Changed to M3
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 2

19 years ago
i wish I had more info like which variable ect. I will try to run purify and
check.
(Reporter)

Comment 3

19 years ago
check out the info at the tail end of the report from purify.

'textWidth' in TextFrame::GetPosition()
(Assignee)

Comment 4

19 years ago
ahh eeeexcellent.  gracias.

Updated

19 years ago
Target Milestone: M3 → M4

Comment 5

19 years ago
Moving to M4

Comment 6

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

Updated

19 years ago

Comment 7

19 years ago
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.
(Reporter)

Comment 8

19 years ago
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).
(Reporter)

Comment 9

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

Comment 10

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

Comment 11

19 years ago
*** Bug 4116 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

19 years ago
Target Milestone: M4 → M5
(Assignee)

Comment 12

19 years ago
not a real problem. i have a fix but not going in now. when tree opens for m5 i
will commit the change
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

19 years ago
should be fixed now thanks

Comment 14

19 years ago
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.

Comment 15

19 years ago
...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.

Updated

19 years ago
Whiteboard: just waiting on reporter/developer verification
(Reporter)

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 16

19 years ago
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.
You need to log in before you can comment on or make changes to this bug.