380704 - compile error [@nsOfflineCacheDevice::Init]

Status: RESOLVED FIXED

(Core :: Networking: Cache, defect)

Description

[Evan Yan]

Sun compiler became unhappy after the check in of bug 370195.

error message:

"nsDiskCacheDeviceSQL.cpp", line 772: Error: A class with a reference member must have a user-defined constructor.
"nsDiskCacheDeviceSQL.cpp", line 773: Error: Cannot use {} to initialize struct.

Comment 1

[Evan Yan]

Attachment: make Sun compiler happy

Comment 2

[Johnny Stenback (:jst)]

Comment on attachment 264838 [details] [diff] [review]
make Sun compiler happy

r+sr=jst

Comment 3

[Alfred Peng]

Checking in netwerk/cache/src/nsDiskCacheDeviceSQL.cpp;
/cvsroot/mozilla/netwerk/cache/src/nsDiskCacheDeviceSQL.cpp,v  <--  nsDiskCacheDeviceSQL.cpp
new revision: 1.8; previous revision: 1.7
done

=> Marked as Fixed

Comment 4

[Alfred Peng]

Sorry to not include that "Patch by [e-mail]" in the log.

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

er, does this patch actually work? Not only are you initializing references with local variables, you are also leaving all the mStatement_* variables uninitialized.

reopening, please fix the patch.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

(cc'ing jst who reviewed this)

Comment 7

[Evan Yan]

What I did in the patch is just using a explicit constructor to initializing the struct, in order to make Sun compiler happy.

I'm not sure why the former code use local variables to initialize references.

Comment 8

[Peter van der Woude [:Peter6]]

This caused Bug 380741

Comment 9

[Mats Palmgren (inactive)]

Changing "aStatement" to "&aStatement" should fix it I think

Comment 10

[Evan Yan]

not in office now. will investigate it in tomorrow morning, that is about ten hours later.

Comment 11

[Evan Yan]

(In reply to comment #9)
> Changing "aStatement" to "&aStatement" should fix it I think
> 
ah, you must be right. Sorry for my mistake on that.

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

yes, indeed. the local variable that I was referring to was the argument to the function, and adding the & should fix it.

Comment 13

[Dave Camp (:dcamp)]

Attachment: add the &

yeah, adding it does fix it.

Comment 14

[Evan Yan]

Dave, Thanks a lot for making the patch!

Comment 15

[(not reading, please use [e-mail] instead)]

as I mentioned to dave, I'm seeing this too on win32.

I'll go land his patch, since he has a verbal r/sr=biesi

 	03d91639()	
 	necko.dll!nsCOMPtr<mozIStorageStatement>::assign_assuming_AddRef(mozIStorageStatement * newPtr=0x00000000)  Line 569	C++
 	necko.dll!nsCOMPtr<mozIStorageStatement>::StartAssignment()  Line 902	C++
 	necko.dll!nsGetterAddRefs<mozIStorageStatement>::operator mozIStorageStatement * *()  Line 1406	C++
>	necko.dll!nsOfflineCacheDevice::Init()  Line 794 + 0x35 bytes	C++
 	necko.dll!nsCacheService::CreateOfflineDevice()  Line 1097 + 0x13 bytes	C++
 	necko.dll!nsCacheService::SearchCacheDevices(nsCString * key=0x09d69270, int policy=1237620, int * collision=0x03d91630)  Line 1448 + 0x8 bytes	C++
 	necko.dll!nsCacheService::ProcessRequest(nsCacheRequest * request=0x09d69270, int calledFromOpenCacheEntry=1, nsICacheEntryDescriptor * * result=0x070403ac)  Line 1241 + 0x10 bytes	C++
 	necko.dll!nsCacheService::OpenCacheEntry(nsCacheSession * session=0x03b033a8, const nsACString_internal & key={...}, int accessRequested=1, int blockingMode=0, nsICacheListener * listener=0x00000000, nsICacheEntryDescriptor * * result=0x070403ac)  Line 1318 + 0x15 bytes	C++
 	necko.dll!nsCacheSession::OpenCacheEntry(const nsACString_internal & key={...}, int accessRequested=1, int blockingMode=0, nsICacheEntryDescriptor * * result=0x070403ac)  Line 106 + 0x1b bytes	C++
 	necko.dll!nsHttpChannel::OpenCacheEntry(int offline=1, int * delayed=0x0012e3f0)  Line 1320 + 0x50 bytes	C++
 	necko.dll!nsHttpChannel::Connect(int firstTime=1)  Line 286 + 0x10 bytes	C++
 	necko.dll!nsHttpChannel::AsyncOpen(nsIStreamListener * listener=0x0a9c9b60, nsISupports * context=0x00000000)  Line 3556 + 0xd bytes	C++
 	xpcom_core.dll!NS_InvokeByIndex_P(nsISupports * that=0x0000001c, unsigned int methodIndex=2, unsigned int paramCount=1238400, nsXPTCVariant * params=0x00d2d4c0)  Line 102	C++
 	xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=28)  Line 2245 + 0x1e bytes	C++
 	xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=CALL_METHOD)  Line 2245 + 0x1e bytes	C++
 	xpc3250.dll!XPC_WN_CallMethod(JSContext * cx=0x03dfce70, JSObject * obj=0x07273fe0, unsigned int argc=2, long * argv=0x0b1950ec, long * vp=0x0012e828)  Line 1467 + 0xe bytes	C++
 	js3250.dll!js_Invoke(JSContext * cx=0x03dfce70, unsigned int argc=2, unsigned int flags=0)  Line 1332 + 0x20 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x03dfce70, unsigned char * pc=0x03bc1fe0, long * result=0x0012eee0)  Line 4025 + 0xf bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x03dfce70, unsigned int argc=0, unsigned int flags=6)  Line 1351 + 0x13 bytes	C
 	js3250.dll!fun_apply(JSContext * cx=0x03dfce70, JSObject * obj=0x00e36740, unsigned int argc=0, long * argv=0x0b19500c, long * rval=0x0012efa4)  Line 1703 + 0xf bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x03dfce70, unsigned int argc=2, unsigned int flags=0)  Line 1332 + 0x20 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x03dfce70, unsigned char * pc=0x03bb60b9, long * result=0x0012f65c)  Line 4025 + 0xf bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x03dfce70, unsigned int argc=1, unsigned int flags=2)  Line 1351 + 0x13 bytes	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x03bda0d0, unsigned short methodIndex=3, const XPTMethodDescriptor * info=0x03dcfe88, nsXPTCMiniVariant * nativeParams=0x0012f9c4)  Line 1419 + 0x14 bytes	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=3, const XPTMethodDescriptor * info=0x03dcfe88, nsXPTCMiniVariant * params=0x0012f9c4)  Line 566	C++
 	xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x03beac08, unsigned int methodIndex=3, unsigned int * args=0x0012fa84, unsigned int * stackBytesToPop=0x0012fa74)  Line 114 + 0x21 bytes	C++
 	xpcom_core.dll!SharedStub()  Line 142	C++
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 387	C++
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 387	C++
 	xpcom_core.dll!nsTimerEvent::Run()  Line 458	C++
 	xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fb28)  Line 483	C++
 	xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00bad2e0, int mayWait=1)  Line 227 + 0x16 bytes	C++
 	gkwidget.dll!nsBaseAppShell::Run()  Line 154 + 0xc bytes	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 171 + 0x1c bytes	C++
 	xul.dll!XRE_main(int argc=2, char * * argv=0x00ba9800, const nsXREAppData * aAppData=0x004036e0)  Line 2824 + 0x25 bytes	C++
 	firefox.exe!main(int argc=2, char * * argv=0x00ba9800)  Line 65 + 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]	

Comment 16

[(not reading, please use [e-mail] instead)]

fix landed, r/sr=biesi (per dcamp)

Checking in cache/src/nsDiskCacheDeviceSQL.cpp;
/cvsroot/mozilla/netwerk/cache/src/nsDiskCacheDeviceSQL.cpp,v  <--  nsDiskCacheD
eviceSQL.cpp
new revision: 1.9; previous revision: 1.8
done