Bug 41295 - MAILMERGE Corrupted PDFs in massmailing
Summary: MAILMERGE Corrupted PDFs in massmailing
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.4.3 release
Hardware: All Windows (All)
: high major
Assignee: Caolán McNamara
Depends on:
Blocks: 34184
  Show dependency treegraph
Reported: 2011-09-28 04:55 UTC by christof.spies
Modified: 2013-06-14 04:56 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

csv data for testing (29.21 KB, text/csv)
2011-09-28 04:55 UTC, christof.spies
Source document with some pdf attachments from my test (124.33 KB, application/x-zip-compressed)
2011-09-28 06:04 UTC, Rainer Bielefeld Retired
tmp file collisions (664 bytes, patch)
2011-11-17 09:19 UTC, Caolán McNamara

Note You need to log in before you can comment on or make changes to this bug.
Description christof.spies 2011-09-28 04:55:36 UTC
Created attachment 51713 [details]
csv data for testing

0. Download the attached file and replace test2@example.com with you email address.
1. New blank writer document
2. Start Mass mail assistent
3. Next (use current document)
4. Next (e mail message)
5.1 Select address list
5.2 Add ...
5.3 Open the attached "address.csv"
5.4 Field delimiter = ,
    text delimiter = "
    dicimal delimiter = .
    thousand delimit = <blank>
    txt contains headline = checked
    Encodung = UTF-8
6. Next (no letter salutation)
7.1 Edit document
7.2 F4 to show data source
7.3 Create 5 new lines and add pull id, c__lastname, c__mail, cp__email in the the first 4 rows and add the text "test1234" in the 5th.
7.4 Back to the mass mail assistent
7.5 Next
8. Next (no individuall changes)
9.1 Send document as Email (last radio button)
9.2 To = cp__email
9.3 Subject = test
9.4 send as Adobe PDF Document
9.5 Send documents

Check you emails and the size of the attachments ... there are more than 30% off the PDF files damaged.

LibreOffice 3.4.3 
OOO340m1 (Build:302)
Windows 7 64bit
Comment 1 Rainer Bielefeld Retired 2011-09-28 05:40:35 UTC
[Reproducible] with "LibreOffice 3.4.3 RC2 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", I receive mails with PDFs between few Bytes and 33kBytes

In Master we should have some fixes, I will test again as soon as a new WIN master what is able to open WRITER documents will be available.
Comment 2 Rainer Bielefeld Retired 2011-09-28 06:01:07 UTC
Same problem with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  d3d1481-3f8994a-2ba0a9f)]"

I would have tested with a more current version, but currently no WIN dev-builds are available. Are the latest fixes in that build?
Comment 3 Rainer Bielefeld Retired 2011-09-28 06:04:25 UTC
Created attachment 51714 [details]
Source document with some pdf attachments from my test

May be damages in the PDF attachments give some hints concerning the problem?
Comment 4 m 2011-09-28 06:17:02 UTC
Tested with 3.3.4 OOO330m19 Build:401
works fine for me
Comment 5 Rainer Bielefeld Retired 2011-09-28 07:18:11 UTC
Thank you for your test! PDF mailmerge broke somewhere after OOo 3.1.1 with lots of lots of problems, and we (most: Caolan) had some heavy efforts here to get it running again. so your hint might be useful for "forensic" concerning this particular problem.
Comment 6 Caolán McNamara 2011-10-04 08:54:51 UTC
my mail server won't let me send 90 emails right after eachother sadly, seeing as it has some anti-spam measures.

This *sounds* like http://cgit.freedesktop.org/libreoffice/libs-extern-sys/commit/?id=491dab7d62dc42a13d56fe82cc33c2fb312ee30f i.e. http://bugs.python.org/issue4768 but that was backported to 3.4.3.
Comment 7 Rainer Bielefeld Retired 2011-10-04 09:38:33 UTC
The python report is to complicated for me.
I also did not send 90 mails, most of attachments are damaged, so 5-10 should be enough.
Comment 8 Caolán McNamara 2011-10-05 06:15:26 UTC
quite possibly windows only, seeing as my 10/20 went through ok. unless its a file length thing where the troublesome versions happen to hit an exact round number boundary.
Comment 9 Rainer Bielefeld Retired 2011-11-11 09:16:21 UTC
Still [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) German UI [(Build ID:  6b0de40-0bc4ff4-ca7e6f5-9125509-ce71330)]" (111111) 

In a first test I only sent 5 mails with some texts, pictures, ..., 2 were ok, 3 damaged.

Then 20 documents like 2011-09-28 06:04 15 seemed ok5, 5 ones damaged
Comment 10 Caolán McNamara 2011-11-16 05:02:37 UTC
right, after setting up fakemail I can now reproduce this apparently windows-only problem.
Comment 11 Caolán McNamara 2011-11-17 09:19:38 UTC
Created attachment 53632 [details]
tmp file collisions
Comment 12 Caolán McNamara 2011-11-17 09:25:09 UTC
caolanm->mstahl: I think this is triggered from 6a5b285548f92135b6eaf220c4d4533854032aa0
e.g. same tmpfile name reused, and the mailmerge makes a *lot* of tmp files. This seems to fix it in testing anyway. Presumably in the !bKeep "I only want a unique name" path, where there is no file created then by getting a new seed every time we make it easy to hand out a file name already handed out.

How about this band-aid, i.e. basically the ye-oldy logic.
Comment 13 Michael Stahl (allotropia) 2011-11-17 10:31:45 UTC

your patch was quite surprising to me,
but looking at the function and what it does now i am shocked:
the stupid thing creates a file with the generated name,
then immediately closes it again, and then later apparently
one can call a function on the TempFile object that will open
the file with the generated name again?
do i understand this right?
(seems that i missed that detail back when i did that fix...)

why don't we have an easy hack to replace this abomination with something sane?

if we don't remove it then i guess your patch could help :)
Comment 14 Caolán McNamara 2011-11-17 13:22:56 UTC
If its used to create a physical temporary file its reasonably sane. If its used to create just a unique file name which is to be safely used as the path to a temp file at some arbitrary point in the future, its not so sane methinks. 

We should get rid of this thing alright, maybe two methods, one when we "just want a temp file created", i.e. just the oslCreateTemp method, and another one for the existing legacy "we want a unique filename which won't be used again for the duration of the program" which is always returned as a path in a private tmpdir created with the other method and uses a radix-36 filename off a static counter.
Comment 16 Stephan Bergmann 2011-11-21 06:11:53 UTC
backported to libreoffice-3-4 (towards 3.4.5) as <http://cgit.freedesktop.org/libreoffice/libs-gui/commit/?h=libreoffice-3-4&id=b5b7699c6a42f6cca7da6d91eac0dada9e48ee35>
Comment 17 Björn Michaelsen 2011-12-23 13:25:59 UTC
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.