Last Comment Bug 537889 - Funambol Mozilla Sync Client add-on Crashes when sending an email @ fnblcomponent.dll
: Funambol Mozilla Sync Client add-on Crashes when sending an email @ fnblcompo...
Status: NEW
[add-on: Funambol][gs]
: crash
Product: Thunderbird
Classification: Client Software
Component: General (show other bugs)
: 3.0
: x86_64 Windows 7
: -- critical with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://gsfn.us/t/17469
: 537905 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-05 00:12 PST by Craig
Modified: 2016-06-17 05:54 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Craig 2010-01-05 00:12:36 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Build Identifier: 3.0

Crash when sending an email, before asking for smtp password
Has crashed with and without attachments, with single recipient and with multiple recipients
Has also crashed when smtp server doesn't use security (no password0

Reproducible: Sometimes

Steps to Reproduce:
1.Compose email
2.add recipient and subject
3.press send
Actual Results:  
crash

Expected Results:  
should send email or ask for smtp password then send email

Crash ID: bp-0fabf650-8997-4b24-b44c-6004f2100105
Comment 1 Mark Banner (:standard8) 2010-01-05 01:10:17 PST
(In reply to comment #0)
> Crash ID: bp-0fabf650-8997-4b24-b44c-6004f2100105

0  	fnblComponent.dll  	fnblComponent.dll@0xdb22  	
1 	fnblComponent.dll 	fnblComponent.dll@0xe788 	

This crash indicates you are using the Funambol Mozilla Sync Client add-on and it is that add-on that is causing the crash.

Have you tried disabling the add-on and then sending email? If it does not crash in that configuration, then it is an issue with the add-on and not with Thunderbird.

Please report your results back here in any case.
Comment 2 timeless 2010-01-05 02:05:32 PST
 syncmlplugin@funambol.com  	1.0b1
Signature	fnblComponent.dll@0xdb22
UUID	0fabf650-8997-4b24-b44c-6004f2100105
Time 	2010-01-05 00:00:25.828787
Uptime	331
Last Crash	358 seconds before submission
Product	Thunderbird
Version	3.0
Build ID	20091204171430
Branch	1.9.1
OS	Windows NT
OS Version	6.1.7100
CPU	x86
CPU Info	GenuineIntel family 6 model 15 stepping 11
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x0
User Comments	
Processor Notes 	
Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	fnblComponent.dll 	fnblComponent.dll@0xdb22 	
1 	fnblComponent.dll 	fnblComponent.dll@0xe788 	

This is a null deref. someone willing to build this should be able to figure out where.

https://mozilla-plugin.forge.funambol.org/svn/mozilla-plugin/trunk/funambol-mozilla-plugin/howtobuild.txt seems to have instructions (Which are incredibly scary)

there is no oom handling.

NS_IMETHODIMP CalProxy::SetCalendar(calICalendar * aCalendar)
    aCalendar->QueryInterface(NS_GET_IID(calICalendar), getter_AddRefs(calendar));

This will crash if aCalendar is null (perfectly valid input, buggy code, matches crash reported here)

NS_IMETHODIMP CalProxy::AddItem(calIItemBase *newItem, nsACString & _retval)
    char* id = getterListener->getReturnedId();
the use of delete[] is scary but possibly correct:
    delete [] id;   id = 0;

NS_IMETHODIMP CalendarGetterListener::OnOperationComplete(calICalendar
this is scary:
    returnedId = stringdup(aId);

 NS_IMETHODIMP CalendarGetterListener::OnGetResult(calICalendar *aCalendar, 
            calItem = (calIItemBase*)aItems[i];
            calItem->GetIcalComponent(getter_AddRefs(icalComp));


This will crash if aItems[i] is null (this could happen if something else passes a slightly unhappy array, buggy code, matches crash reported here)

CalendarSyncSource::CalendarSyncSource(const WCHAR* name, SyncSourceConfig* sc) 
    NS_GetComponentManager(getter_AddRefs(compMan));
    NS_GetServiceManager(getter_AddRefs(servMan));

    compMan->CreateInstanceByContractID(CAL_PROXY_CONTRACTID,
                                        0,
                                        NS_GET_IID(calIProxy), 
                                        getter_AddRefs(calTestProxy));

this could crash if at some point the component manager stops being supported (unlikely, and it'd require a rewrite of the component, but callers are still supposed to check, we have obsoleted/deprecated frozen things in the past).

    servMan->GetServiceByContractID("@mozilla.org/xpcomproxy;1",
                NS_GET_IID(nsIProxyObjectManager), 
                getter_AddRefs(proxyMan));

    proxyMan->GetProxyForObject(NS_UI_THREAD_EVENTQ,

this could crash, as nsIProxyObjectManager isn't marked as frozen so even if the contract remains it'd fail if we change the interface (unlikely, but legal). the crash would match the crash reported here (minus the fact that this file should crash much earlier in life)

    if(!NS_SUCCEEDED(servMan->GetServiceByContractID("@mozilla.org/calendar/manager;1",

Callers should use NS_FAILED ....

    calManager->GetCalendars(&calCount, &calendars);
no rv check (bad form, outputs in xpcom are only valid if the result is NS_SUCCEEDED). I believe calendars** is leaked on success

    for(int i=0; i<(int)calCount; i++) {
        calendars[i]->QueryInterface(NS_GET_IID(calICalendar), 
                                        getter_AddRefs(aCalendar));

QIs can fail and should be checked. Plus do_QueryInterface should be used instead....

        aCalendar->GetUri(getter_AddRefs(calUri));

the crash would be here, and again, it'd be a null pointer deref matching the crash reported here)

again result should be checked

        calUri->GetSpec(calSpec);

or you'd crash here (matches crash reported here)

            aCalendar->QueryInterface(NS_GET_IID(calICalendar), 
                                        getter_AddRefs(calendar));

QIs can fail and should be checked. Plus do_QueryInterface should be used instead....

            calendar->GetName(calName);

the crash would be here, and again, it'd be a null pointer deref matching the crash reported here)

Roughly this extension needs a lot of love. Please find some developer from Funambol and ask them to fix up their code (at least based on these two or three general comments).

I certainly wouldn't use this extension w/o getting it fixed if i were you.
Comment 3 Ludovic Hirlimann [:Usul] 2010-01-05 03:48:31 PST
bug is filled at https://mozilla-plugin.forge.funambol.org/servlets/tracking/id/SC185.
Comment 4 timeless 2010-01-05 07:42:01 PST
*** Bug 537905 has been marked as a duplicate of this bug. ***
Comment 5 Wayne Mery (:wsmwk, NI for questions) 2010-09-03 08:21:09 PDT
#14 according to crash-stats (combining the different signatures)

"Me and my users are stuck with Thunderbird 2.x because funambol sync plugin doesn't work yet with thunderbird 3.x." ... a quote from http://weblogs.mozillazine.org/calendar/2010/09/how_are_lightning_users_doing.html#comment-2729297

no movement in https://mozilla-plugin.forge.funambol.org/servlets/tracking/id/SC185 and roland still has this on https://wiki.mozilla.org/Thunderbird/Thunderbird3.1SupportIssues

=> NEW to get this off the unconfirmed list - even though it's not a bug in thunderbird

Note You need to log in before you can comment on or make changes to this bug.