Created attachment 44583 [details]
Better Sample document

With this document without any address field I can reproduce the crash in step 8 when sending the document as PDF attachment.

As expected this problem still exists  with "LibreOffice 3.4Beta2  - WIN7  Home Premium (64bit) German UI [DEV300m103 (Build:1)]" 

My suspect: This one might have the same roots as 
"Bug 35937 - Mailmerge makes LibreOffice crash if the master documents contains formulas".

Created attachment 46731 [details]
New Minimum Sample Document

The problem is caused by the DRAWing element, what will crash Email-Mailmerge wizard after step 6

Post bug 35937 fix in master I can't reproduce this, or see anything under valgrind under Linux. Which doesn't mean its fixed, but means I cannot see a remaining problem in this area.

Still crashes for me on 3.4rc1, and Mac OSX, enclosed apple crash trace. I used the minimal sample doc provided in this report.

Changing status to new/confirmed, platform/OS all.


Alex

Created attachment 47190 [details]
apple crash trace during mailmerge with doc containing image

I can't run valgrind on Mac on this because the mailmerge requires user input through context dialogs, and they not only do not work (as in, nothing can be entered) when running valgrind, but also cause the app to systematically sigabrt.

Alex

my comments are for post 3.4 FWIW, the fix for the ole2 copything is in what will be 3.4.1

Created attachment 49575 [details]
does this still happen for people in 3.4.X ?

Created attachment 49577 [details]
Error message from latest test 

@Caolán:
I did 1 test with my "New Minimum Sample Document":
No step 6 crash   but
Error message as attached (What seems to be something completely different (Bug 36763 - Mail Merge E-Mail stops with error "Invalid Address")

hmm, for me what I think I'm seeing is that with e.g. internal python the python ssl.so is linked against the system libssl, but liboox links to a static libssl.a and re-exports those symbols, which are from a different version

Hi Caolàn,

Still crashes for me on Mac OSX 10.6.8 with 3.4.2rc2. Attached crash report trace.

Alex

Created attachment 49580 [details]
apple crash trace with email mailmerge doc containing picture

(In reply to comment #13)
> Created an attachment (id=49580) [details]
> apple crash trace with email mailmerge doc containing picture

Forgot to mention where it crashes : at Step 8 of the wizard, i.e. when I click on the button to finish.

I have tested normal e-mail sending of a doc (Send as e-mail with attached doc from within LibreOffice) using Mail.app and that appears to work fine.


Alex

hmm, and #13 is a different trace.

caolanm->:alex for your latest crash, what is the "source" for your mail merge ? That specific crash looks sort of like a crash trying to get a column out of the database. I wonder if its of a type all platforms have e.g. a ods, csv, manually created one from the edit->addresses step, or perhaps some mac addressbook integration thing.

Pity there isn't line numbers to see which exact column it is and where exactly that one is thrown from at least.

Hi Caolàn,

It is from a mysql contacts db, so an address book to all intents and purposes. The db is registered within LibO and opens fine via the mysql native connector extension. Anything else I might add ?


Alex

Ok, so I tried to redo the whole thing, after having defined the Mac Address Book as the default Address datasource for LibO. After dragging dropping 2 fields from my address book onto the test document, I then went to the Mailmerge assistant. The app crashed spontaneously whilst attempting to call up the first page of the wizard.

A crash trace is attached. Doesn't seem very stable...

Alex

Created attachment 49581 [details]
apple crash trace using Mac address book as datasource

indeed, so to date what I have is...

a) original crash on windows which I think I may have fixed with bug 35937

b) dodgy mix of openssl symbols which I can see under Linux x86_64, sent an email to the list about that, that's fixable anyway, just a matter of the right way to do it.

c) uncaught exception from lcl_GetColumnValueOf with mysql data source on Mac

d) CFNumberGetType crash in mac address book

without a mac I can't do anything about d.

I don't think any of these are actually directly related to the mailmerge code itself, its just triggering them.

OK, my guess is that last crash report from Comments 18 & 19 was linked to the
Address datasource wizard because I just tried the whole e-mail mailermge again
again and get a crash at the end of the very last step, i.e. when attempting to
send the documents as e-mail. The crash trace I got this time is the same as
the one posted at 2011-07-26 08:01 PDT.

So for me at least, the crash is reproducible.


Alex

Created attachment 49583 [details]
apple crashrep trace using mac addressbook as datasource

The latest crash rep I submitted also shows the same line :

lcl_GetColumnValueOf

but this is from a Mac address book as data source, so it appears to be independent of the data source used.


Alex

The corresponding line of code appears to be found in mmoutput.cxx, line 101 :

::rtl::OUString lcl_GetColumnValueOf(const ::rtl::OUString& rColumn, Reference < container::XNameAccess>& rxColAccess )
{
    ::rtl::OUString sRet;
    if(rxColAccess->hasByName(rColumn))
    {
        Any aCol = rxColAccess->getByName(rColumn);
        Reference< sdb::XColumn > xColumn;
        aCol >>= xColumn;
        if(xColumn.is())
            sRet = xColumn->getString();
    }
    return sRet;

(In reply to comment #24)
> The corresponding line of code appears to be found in mmoutput.cxx, line 101 :
> 
> ::rtl::OUString lcl_GetColumnValueOf(const ::rtl::OUString& rColumn, Reference
> < container::XNameAccess>& rxColAccess )
> {
>     ::rtl::OUString sRet;
>     if(rxColAccess->hasByName(rColumn))
>     {
>         Any aCol = rxColAccess->getByName(rColumn);
>         Reference< sdb::XColumn > xColumn;
>         aCol >>= xColumn;
>         if(xColumn.is())
>             sRet = xColumn->getString();
>     }
>     return sRet;


Sorry, that should read mmoutputpage.cxx, line 101


Alex

yeah, but its the location of where that dbtools::throwSQLException got called from which is the interesting missing bit.

Created attachment 49590 [details]
ah well, can probably make it not crash with this anyway

This bug has sort mutated into a bit of a "difficult to know when its fixed" bug.

Assuming a) is already fixed

for b) http://cgit.freedesktop.org/libreoffice/libs-extern/commit/?id=1022b20da6e234349b9c8d094670297a8e523c86 for the dodgy mixed openssl symbols which I could reproduce under Linux x86_64

for c) http://cgit.freedesktop.org/libreoffice/writer/commit/?id=6e5e307f7cdd9e05d9c4e9d2cda71152dd75021c to catch the exception which is apparently being thrown (for a still unknown reason) under MacOSX

ignoring additional bug d)

caolanm->alex: Are you in a position to be able to build a MacOSX build of your own with the additional fix above ? 

If not then tomorrows MacOSX daily at http://dev-builds.libreoffice.org/daily/MacOSX_10.6.7_Intel_no-moz/master/ should include the fix for testing. i.e. something >= 2011-07-28.

Because I can't tell *why* the exception was thrown there is quite a possibility that this fix will be necessary but not sufficient, so no point attempting to backport c) to a stable branch unless it is known to be sufficient.

Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.