Bug 121951 - CRASH: Fatal error with mailmerge
Summary: CRASH: Fatal error with mailmerge
Status: RESOLVED DUPLICATE of bug 118728
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: haveBacktrace
Depends on:
Blocks: Mail-Merge
  Show dependency treegraph
Reported: 2018-12-06 21:58 UTC by albos
Modified: 2018-12-16 19:16 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

gdb bt (5.22 KB, text/plain)
2018-12-08 17:35 UTC, Julien Nabet
bt from "catch throw" (19.67 KB, text/plain)
2018-12-08 17:44 UTC, Julien Nabet
bt with debug symbols (9.04 KB, text/plain)
2018-12-08 18:47 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description albos 2018-12-06 21:58:16 UTC
Toute tentative de publipostage en utilisant l'impression se solde par une erreur fatale. Par ailleurs, l'association avec le fichier de base de donnée est systématiquement perdu.

Steps to Reproduce:
1.Fichier texte : edition / changer de base de donnée : classeur .ods
2.Glisser déposer des champs
3.Impression / Imprimer une lettre formulaire : oui / Dans un fichier

Actual Results:
Fatal Error

Expected Results:
Création fichier avec documents fusionnés

Reproducible: Always

User Profile Reset: Yes

OpenGL enabled: Yes

Additional Info:
Création fichier avec documents fusionnés
Comment 1 Julien Nabet 2018-12-07 08:15:44 UTC
Quick translation:
Every try to use mailmerge fails with fatal error. Moreover, the mapping with a file containing the database is always lost.

Steps to reproduce:
- text file: edit/change DB : worksheet .ods
- drop fields
- print/print form letter : yes / in a file

Actual Results:
Fatal error

Expected Results:
File creation with merged documents.
Comment 2 himajin100000 2018-12-07 10:48:12 UTC
Similar problem is reported on Japanese ask.libreoffice.org


Though I did not know enough about the cause, only as a tentative patch , I applied the following modification on my environment as given in the forementioned forum, and now I see no errors.

1. comment-out the following three lines in void SbaTableQueryBrowser::unloadAndCleanup( bool _bDisposeConnection )

Reference< XLoadable > xLoadable = getLoadable();
if (xLoadable->isLoaded())

2. explicitly specify false as the parameter of unloadAndCleanup, and avoid relying on default parameter true

so that disposeConnection is not executed.

3. comment out the following three lines


DBTreeListUserData* pData = static_cast< DBTreeListUserData* >( pDataSourceEntry->GetUserData() );
pDataSourceEntry->SetUserData( nullptr );
delete pData;

by doing all these three, LibreOffice stopped running FPreaparedStatement::close

I'm not going to submit the patch myself for the inadequate understanding. I would be happy if someone helps me.
Comment 3 Julien Nabet 2018-12-07 10:54:16 UTC
Lionel: thought you might be interested in this one.
Indeed, himajin100000 proposed some changes concerning dbaccess part.
Comment 4 Lionel Elie Mamane 2018-12-07 15:51:08 UTC
Would someone have a backtrace of the crash?
Comment 5 Julien Nabet 2018-12-08 17:35:55 UTC
Created attachment 147386 [details]
gdb bt

On pc Debian x86-64 with master sources updated today, I could reproduce this.

bt isn't very interesting here but I also included logs which show some interesting exceptions.
Comment 6 Julien Nabet 2018-12-08 17:44:33 UTC
Created attachment 147387 [details]
bt from "catch throw"

Here's the bt.
I noticed sItem="AportisDoc Palm DB" ("Palm" in 2018!!)
Comment 7 Julien Nabet 2018-12-08 18:47:29 UTC
Created attachment 147390 [details]
bt with debug symbols

The previous bt seems unrelated.
This one with
#1  0x00007fffec0af4ae in connectivity::checkDisposed(bool) (_bThrow=true) at /home/julien/lo/libreoffice/connectivity/source/commontools/dbtools.cxx:1941
#2  0x00007fffb114af30 in dbaccess::ORowSetBase::checkCache() (this=0x55555cb333a0) at /home/julien/lo/libreoffice/dbaccess/source/core/api/RowSetBase.cxx:1281
#3  0x00007fffb1148110 in dbaccess::ORowSetBase::getRow() (this=0x55555cb333a0) at /home/julien/lo/libreoffice/dbaccess/source/core/api/RowSetBase.cxx:843
#4  0x00007fffde3fea42 in SwDBManager::MergeMailFiles(SwWrtShell*, SwMergeDescriptor const&) (this=0x55555a9feb80, pSourceShell=0x55555cc4abe0, rMergeDescriptor=...)
    at /home/julien/lo/libreoffice/sw/source/uibase/dbui/dbmgr.cxx:1584

seems more relevant.
Comment 8 Xisco Faulí 2018-12-12 17:58:07 UTC
Hi Julien Nabet,
could you please provide the steps and document to reproduce this issue ? Does it happen everytime or just once ? bug 118728 ?
Comment 9 Julien Nabet 2018-12-16 19:15:11 UTC
(In reply to Xisco Faulí from comment #8)
> Hi Julien Nabet,
> could you please provide the steps and document to reproduce this issue ?
> Does it happen everytime or just once ? bug 118728 ?

Here are the steps:
- create an ods file with 2 columns (name + surname)
add 1 or lines of data
save file and close it
- create an odt file
- Edit/Exchange Database...
- click Browse button, then select ods file
- click Close button

- Edit Datasource (or Ctrl+Shift+F4)
- Select ods sources, Tables, Sheet1
- Select "name" column and drag it on the document to add a field

- File/Print...
-> a message box appears:
"Your document contains address database fields. Do you want to print a letter form?"
- click "Yes"
-> Mail merge dialog appears
- click "File" radio button at top right column (just below "Output")
- click "OK" button
-> name dialog appears
- type a name
- click Save button
=> crash
Comment 10 Julien Nabet 2018-12-16 19:16:57 UTC
Yes it happens everytime and yes it corresponds exactly to tdf#118728
Let's put this one as dup.
Good catch Xisco!

*** This bug has been marked as a duplicate of bug 118728 ***