Closed Bug 135278 Opened 23 years ago Closed 23 years ago

nsDependentSingleFragmentCSubstring assertions

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.0.1

People

(Reporter: rbs, Assigned: jst)

References

Details

(Whiteboard: [HAVE FIX])

Attachments

(2 files)

I am hitting an assertion when nsGenericDOMDataNode::GetData() has to return am empty string. There is a comment in the code that seems to suggest that such problems were anticipated, but there is apparently no protection for the case of nsDependentSingleFragmentCSubstring. See also bug 121925 - "nsDependentCString assertions". Code from where the assertion is originating: ============================================= nsresult nsGenericDOMDataNode::GetData(nsAString& aData) { if (mText.Is2b()) { aData.Assign(mText.Get2b(), mText.GetLength()); } else { // Must use Substring() since nsDependentCString() requires null // terminated strings. const char *data = mText.Get1b(); CopyASCIItoUCS2(Substring(data, data + mText.GetLength()), aData); } return NS_OK; } Stack trace: ============ NTDLL! 77f9eea9() nsDebug::Assertion(const char * 0x101073e4 `string', const char * 0x10107284 `string', const char * 0x101073a8 `string', int 203) line 291 + 13 bytes nsDependentSingleFragmentCSubstring::Rebind(const char * 0x00000000, const char * 0x00000000) line 203 + 37 bytes nsDependentSingleFragmentCSubstring::nsDependentSingleFragmentCSubstring(const char * 0x00000000, const char * 0x00000000) line 216 + 51 bytes Substring(const char * const & 0x00000000, const char * const & 0x00000000) line 282 + 21 bytes nsGenericDOMDataNode::GetData(nsAString & {...}) line 437 + 40 bytes nsTextNode::GetData(nsTextNode * const 0x03d9c69c, nsAString & {...}) line 59 + 18 bytes XPTC_InvokeByIndex(nsISupports * 0x03d9c69c, unsigned int 28, unsigned int 1, nsXPTCVariant * 0x0012d5f0) line 106 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_GETTER) line 2025 + 42 bytes XPCWrappedNative::GetAttribute(XPCCallContext & {...}) line 1823 + 14 bytes XPC_WN_GetterSetter(JSContext * 0x03b4f2a8, JSObject * 0x03cdb110, unsigned int 0, long * 0x03c8540c, long * 0x0012d8e0) line 1298 + 12 bytes js_Invoke(JSContext * 0x03b4f2a8, unsigned int 0, unsigned int 2) line 788 + 23 bytes js_InternalInvoke(JSContext * 0x03b4f2a8, JSObject * 0x03cdb110, long 63811992, unsigned int 0, unsigned int 0, long * 0x00000000, long * 0x0012e6e0) line 880 + 20 bytes js_GetProperty(JSContext * 0x03b4f2a8, JSObject * 0x03cdb110, long 25483168, long * 0x0012e6e0) line 2502 + 45 bytes js_Interpret(JSContext * 0x03b4f2a8, long * 0x0012e890) line 2576 + 2032 bytes js_Invoke(JSContext * 0x03b4f2a8, unsigned int 1, unsigned int 2) line 805 + 13 bytes js_InternalInvoke(JSContext * 0x03b4f2a8, JSObject * 0x03a3e538, long 61074728, unsigned int 0, unsigned int 1, long * 0x0012eae8, long * 0x0012e9b8) line 880 + 20 bytes JS_CallFunctionValue(JSContext * 0x03b4f2a8, JSObject * 0x03a3e538, long 61074728, unsigned int 1, long * 0x0012eae8, long * 0x0012e9b8) line 3412 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x017c60a8, void * 0x03a3e538, void * 0x03a3ed28, unsigned int 1, void * 0x0012eae8, int * 0x0012eaec, int 0) line 1016 + 33 bytes nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03d05748, nsIDOMEvent * 0x032b45e8) line 180 + 77 bytes nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03c60d28, nsIDOMEvent * 0x032b45e8, nsIDOMEventTarget * 0x03cadd90, unsigned int 1, unsigned int 7) line 1217 + 20 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x03d85768, nsIPresContext * 0x03db4da0, nsEvent * 0x0012f278, nsIDOMEvent * * 0x0012f1d4, nsIDOMEventTarget * 0x03cadd90, unsigned int 7, nsEventStatus * 0x0012f2a0) line 1890 + 36 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x03cadd80, nsIPresContext * 0x03db4da0, nsEvent * 0x0012f278, nsIDOMEvent * * 0x0012f1d4, unsigned int 1, nsEventStatus * 0x0012f2a0) line 697 DocumentViewerImpl::LoadComplete(DocumentViewerImpl * const 0x03d82338, unsigned int 0) line 1396 + 56 bytes nsDocShell::EndPageLoad(nsIWebProgress * 0x0391ebfc, nsIChannel * 0x03965e10, unsigned int 0) line 3878 nsWebShell::EndPageLoad(nsIWebProgress * 0x0391ebfc, nsIChannel * 0x03965e10, unsigned int 0) line 731 nsDocShell::OnStateChange(nsDocShell * const 0x0394d2ec, nsIWebProgress * 0x0391ebfc, nsIRequest * 0x03965e10, int 131088, unsigned int 0) line 3795 nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x0391ebfc, nsIRequest * 0x03965e10, int 131088, unsigned int 0) line 1105 nsDocLoaderImpl::doStopDocumentLoad(nsIRequest * 0x03965e10, unsigned int 0) line 744 nsDocLoaderImpl::DocLoaderIsEmpty() line 642 nsDocLoaderImpl::DocLoaderIsEmpty() line 645 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x03d19fcc, nsIRequest * 0x03c587d0, nsISupports * 0x00000000, unsigned int 0) line 573 nsLoadGroup::RemoveRequest(nsLoadGroup * const 0x03d1a0a0, nsIRequest * 0x03c587d0, nsISupports * 0x00000000, unsigned int 0) line 526 + 35 bytes nsStreamIOChannel::OnStopRequest(nsStreamIOChannel * const 0x03c587d4, nsIRequest * 0x03c588fc, nsISupports * 0x00000000, unsigned int 0) line 486 nsOnStopRequestEvent::HandleEvent() line 213 nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x03d259dc) line 116 PL_HandleEvent(PLEvent * 0x03d259dc) line 596 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x010c3068) line 526 + 9 bytes _md_EventReceiverProc(HWND__ * 0x008903b4, unsigned int 49488, unsigned int 0, long 17576040) line 1077 + 9 bytes USER32! 77e148dc() USER32! 77e14aa7() USER32! 77e266fd() nsAppShellService::Run(nsAppShellService * const 0x017991e8) line 309 main1(int 1, char * * 0x00304e70, nsISupports * 0x00000000) line 1415 + 32 bytes main(int 1, char * * 0x00304e70) line 1763 + 37 bytes mainCRTStartup() line 338 + 17 bytes
Not a string library bug. The fix should be simple: if (data) CopyASCII... else aData.Truncate();
Assignee: jaggernaut → jst
Component: String → DOM Other
QA Contact: scc → gerardok
Should data even ever be allowed to be |0| there? That implies we're creating "null" text fragments, seems like a waste.
Empty text nodes won't have any buffer in them, so yes, data can be null.
Attached patch Proposed fix.Splinter Review
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla1.0.1
Comment on attachment 77558 [details] [diff] [review] Proposed fix. sr=jag
Attachment #77558 - Flags: review+ → superreview+
*** Bug 143458 has been marked as a duplicate of this bug. ***
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: