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

DownloadProgressListener's onProgressChange() causes "A loss of precision for double floating point is detected" warning in debug build

VERIFIED FIXED

Status

()

Toolkit
Downloads API
VERIFIED FIXED
11 years ago
9 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

DownloadProgressListener's onProgressChange() causes "A loss of precision for double floating point is detected" warning in debug build

WARNING: A loss of precision for double floating point is detected.
         The result of any operation on doubles can be meaningless.
         A possible cause is missing code to restore FPU state, see
         bug 360282 for details.

DownloadProgressListener's onProgressChange() causes broken FPU warning in debug builds when i download particular http://www.oersted.co.jp/~emk/2007/01/fx-351949.zip

it starts happening around 1.2 MB of the download

the code in question is http://lxr.mozilla.org/seamonkey/source/toolkit/mozapps/downloads/content/DownloadProgressListener.js#77

here's my stack:

 	js3250.dll!js_dtoa(double d=0.50585937500000000, int mode=3, int biasUp=1, int ndigits=1, int * decpt=0x0012eb64, int * sign=0x0012eb6c, char * * rve=0x0012eb70, char * buf=0x0012ebc2, unsigned int bufsize=123)  Line 2435	C
 	js3250.dll!JS_dtostr(char * buffer=0x0012ebc0, unsigned int bufferSize=125, JSDToStrMode mode=DTOSTR_FIXED, int precision=1, double d=1.3505859375000000)  Line 2795 + 0x3e bytes	C
 	js3250.dll!num_to(JSContext * cx=0x02c89a38, JSObject * obj=0x04aad592, unsigned int argc=1, long * argv=0x10cb350c, long * rval=0x0012ecec, JSDToStrMode zeroArgMode=DTOSTR_FIXED, JSDToStrMode oneArgMode=DTOSTR_FIXED, long precisionMin=-20, long precisionMax=100, long precisionOffset=0)  Line 448 + 0x2d bytes	C
 	js3250.dll!num_toFixed(JSContext * cx=0x02c89a38, JSObject * obj=0x04aad592, unsigned int argc=1, long * argv=0x10cb350c, long * rval=0x0012ecec)  Line 464 + 0x23 bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x02c89a38, unsigned int argc=1, unsigned int flags=0)  Line 1348 + 0x20 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x02c89a38, unsigned char * pc=0x00d62914, long * result=0x0012f390)  Line 4059 + 0xf bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x02c89a38, unsigned int argc=7, unsigned int flags=2)  Line 1367 + 0x13 bytes	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x04c74bc8, unsigned short methodIndex=6, const XPTMethodDescriptor * info=0x10c17f10, nsXPTCMiniVariant * nativeParams=0x0012f6f8)  Line 1419 + 0x14 bytes	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=6, const XPTMethodDescriptor * info=0x10c17f10, nsXPTCMiniVariant * params=0x0012f6f8)  Line 531	C++
 	xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x04bf28f8, unsigned int methodIndex=6, unsigned int * args=0x0012f7b8, unsigned int * stackBytesToPop=0x0012f7a8)  Line 114 + 0x21 bytes	C++
 	xpcom_core.dll!SharedStub()  Line 142	C++
>	tkitcmps.dll!nsDownload::OnProgressChange64(nsIWebProgress * aWebProgress=0x00000000, nsIRequest * aRequest=0x10b5a6a0, __int64 aCurSelfProgress=1416524, __int64 aMaxSelfProgress=8816625, __int64 aCurTotalProgress=1416524, __int64 aMaxTotalProgress=8816625)  Line 2065	C++
 	tkitcmps.dll!nsDownload::OnProgressChange64(nsIWebProgress * aWebProgress=0x00000000, nsIRequest * aRequest=0x10b5a6a0, __int64 aCurSelfProgress=1416524, __int64 aMaxSelfProgress=8816625, __int64 aCurTotalProgress=1416524, __int64 aMaxTotalProgress=8816625)  Line 2065	C++
 	tkitcmps.dll!nsDownloadProxy::OnProgressChange64(nsIWebProgress * aWebProgress=0x00000000, nsIRequest * aRequest=0x10b5a6a0, __int64 aCurSelfProgress=1416524, __int64 aMaxSelfProgress=8816625, __int64 aCurTotalProgress=1416524, __int64 aMaxTotalProgress=8816625)  Line 221 + 0x41 bytes	C++
 	docshell.dll!nsExternalAppHandler::OnDataAvailable(nsIRequest * request=0x10b5a6a0, nsISupports * aCtxt=0x00000000, nsIInputStream * inStr=0x04ac24a8, unsigned int sourceOffset=1412330, unsigned int count=0)  Line 2065	C++
 	docshell.dll!nsDocumentOpenInfo::OnDataAvailable(nsIRequest * request=0x10b5a6a0, nsISupports * aCtxt=0x00000000, nsIInputStream * inStr=0x04ac24a8, unsigned int sourceOffset=1412330, unsigned int count=4194)  Line 360 + 0x30 bytes	C++
 	necko.dll!nsStreamListenerTee::OnDataAvailable(nsIRequest * request=0x10b5a6a0, nsISupports * context=0x00000000, nsIInputStream * input=0x04c2dc90, unsigned int offset=1412330, unsigned int count=4194)  Line 97 + 0x35 bytes	C++
 	necko.dll!nsHttpChannel::OnDataAvailable(nsIRequest * request=0x04d0b5c8, nsISupports * ctxt=0x00000000, nsIInputStream * input=0x04c2dc90, unsigned int offset=1412330, unsigned int count=4194)  Line 4116 + 0x5d bytes	C++
 	necko.dll!nsInputStreamPump::OnStateTransfer()  Line 503 + 0x40 bytes	C++
 	necko.dll!nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream * stream=0x04c2dc90)  Line 393 + 0xb bytes	C++
 	xpcom_core.dll!nsInputStreamReadyEvent::Run()  Line 112	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fbc4)  Line 483	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00b8f840, int mayWait=1)  Line 225 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 153 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 171 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=1, char * * argv=0x00b8b710, const nsXREAppData * aAppData=0x004036b4)  Line 2513 + 0x25 bytes	C++
 	firefox.exe!main(int argc=1, char * * argv=0x00b8b710)  Line 61 + 0x13 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!7c816fd7() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
No longer depends on: 360282

Comment 1

11 years ago
Maybe the same as bug 362641? That bug also mentions JS toFixed. As far as I understand, the JS code shouldn't be able to break FPU anyway.
Depends on: 362641
according to gcc macro about fpu the fpu is in double precision, though the macro   warns it may be insufficient for the task.

Comment 3

10 years ago
Does anyone still see this? I don't anymore, but I filed the patch for the depends-on-bug 362641

Comment 4

10 years ago
Fixed by bug 362641.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → FIXED

Updated

10 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.