Florian - this looks like something that TDF would need to chase to fix
? a nice list of things to do from Pedro; is this something you can
handle ?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
Worth checking for symbol conflicts between dbaccess and mergedlibs I
guess; I did a quick:
objdump -T instdir/program/libdbtoolslo.so | c++filt | grep -v
'\*UND\*' | grep -v 'connectivity::' | grep -v 'dbtools::' |
grep -v 'non-virtual thunk to connectivity::' | grep -v 'non-virtual
Seems this creates a nasty a11y bug; see bug#71511 - input there
appreciated.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/628105
Title:
[Upstream] Text not black in
In general not using gnome-vfs at all is what makes most sense ;-)
gio - if anything - but surely KIO uses paths into a FUSE mount just like GNOME
does - making that mostly pointless ?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
There was a plausible patch for a similar bug to this somewhere that I
saw recently, some KDE4 specific locking change I was CC'd on. I
couldn't review that beyond thinking it looked sensible - not a great
insight into how that works ...
--
You received this bug notification because you are a
Jan - any thoughts on this - it sounds bad; I had hoped your patch would
help here :-)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/1236012
Title:
[KUBUNTU] Calc freezes screen
Ah - I saw it in gerrit:
https://gerrit.libreoffice.org/6685
Jan - your patch looks plausible; I'd love to have it in 4.2 - but you
realise that by touching the KDE backend you become the maintainer of it
? ;-) if you're willing to take that on - that's excellent by me ! =)
--
You received
Hi Emily - if the coretext work fixes this (and I'd encourage you to try
out Beta2 which should have yet better support), it is rather unlikely
(it's very invasive and somewhat risky) that we will back-port this to
4.0 or anything before 4.1. As such - if it's fixed in 4.1 - we should
prolly close
rpr - if Miklos would like it as a separate bug, since he's the expert
here, and since all bugs are basically specialisations of the something
doesn't work bug :-) I'll file this as a separate issue. See bug #69894
--
You received this bug notification because you are a member of Desktop
Great work Tomaz ! :-) thanks so much for implementing that. Any chance
of a nice screenshot at:
https://wiki.documentfoundation.org/ReleaseNotes/4.2#Writer
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
As it happens Miklos is working on this bug right now for a Collabora
customer :-) It's certainly not a trivial one; but let me CC him.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to openoffice.org in Ubuntu.
If this affects 3.6 it should be a 3.6 MAB, not 4.1 - so moving ...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/1150956
Title:
LibreOffice Calc's RATE function sometimes
I can no longer reproduce:
https://bugs.freedesktop.org/show_bug.cgi?id=57176#c2 on either the 4.0
or 4.1 / master branches.
Isolating and back-porting (if possible) the conditional formatting code
to 3.6 seems unlikely to happen before the last 3.6 release (3.6.7), but
if some developer wants to
propose remove: bug#58819 it looks like a reasonably normal interop.
problem - arguably data-loss, but export to OOXML has plenty of similar
issues; pending Miklos' input.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in
3126 1357235495.356292 connect(3, {sa_family=AF_FILE,
path=/tmp/OSL_PIPE_1000_SingleOfficeIPC_29564c0f238622cbf196bdbd1cd3df2},
110) = 0
3126 1357235495.377358 getcwd(/home/zuidj, 4096) = 12
3126 1357235495.377474 write(3,
InternalIPC::Arguments1file:///home/zuidj,-writer\0, 50) = 50
3126
The official, generic Linux builds at http://www.libreoffice.org/download
are built --enable-gnome-vfs --disable-gio, which does make a difference
Seems like that is disabled on the -4-0 branch (oddly) - so marking a
duplicate.
*** This bug has been marked as a duplicate of bug 64311 ***
--
Can you test again with a LibreOffice 4.0.2 pre-release from:
http://www.libreoffice.org/download/pre-releases/
My hope is that this is another dup of bug#54275 or bug#59022 - both
fixed there.
Thanks.
--
You received this bug notification because you are a member of Desktop
Packages, which
I had a recollection that you did some master-page fixing recently David
- was this a duplicate ? :-)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/641175
Title:
[Upstream]
*** Bug 58320 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/1069757
Title:
[Upstream] Libreoffice: problems with saving docs to
Thanks for the fix Stephan - merged it to: -4-0 for 4.0.3 - might be
nice to have it in gerrit for the 4.0.2 branch ? [ needs another couple
of reviews ]
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
It'd be great to back-port David's fix to -4-0 - better I guess would be
a systematic fix of this kind of undo problem in impress and an
understanding of where these indicees started to go wrong, why we
regressed here better some unit tests but ... ;-) since David's
working on it - I fully expect
It'd be great to back-port David's fix to -4-0 - better I guess would be
a systematic fix of this kind of undo problem in impress and an
understanding of where these indicees started to go wrong, why we
regressed here better some unit tests but ... ;-) since David's
working on it - I fully expect
Can't reproduce with master, 4.0 latest, 3.5 suse version, or 3.6.1.2 on SUSE.
In every case I have one hidden comment, which when shown shows up in black
fonts on a yellow note background as ~expected.
Can someone attach a screenshot of this ? Does it do the same with a
clean profile ? what
Noel - as I recall you did a load of fixing in this area for a recent
LibreOffice - perhaps you can help unwind this.
Please avoid cluttering the bug with details about 3.5.x versions -
development of and new releases for that branch is long dead. Also
anything prior to 3.6.2 is also not that
Thanks Till - so we don't need to start parsing the PPDs and black-
listing known-broken printer drivers based on:
If any of those attributes says the driver can handle
application/vnd.cups-pdf or application/vnd.cups-postscript by
running a program to do it (i.e. any filter other than -),
Any chance of a valgrind trace [ the debugging symbols are helpful - but
valgrind should be even sweeter ;-],
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/949997
Title:
It -looks- like the undo action itself is the broken bit - which appears
not to remove the object from the slide itself leaving it owned by the
SfxListUndoAction and also linked to in the slide. Switching the master-
page just clears the undo queue and forces the crash sooner (that would
otherwise
Created attachment 66770
cleaner log
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/785518
Title:
[Upstream] soffice.bin crashed with SIGSEGV in SdrEndTextEdit()
Status in
I'm just being a lamer - this is easy to reproduce here; I'll poke at
it...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/949997
Title:
[Upstream] Ctrl + z and Enter soffice.bin
It -looks- like the undo action itself is the broken bit - which appears
not to remove the object from the slide itself leaving it owned by the
SfxListUndoAction and also linked to in the slide. Switching the master-
page just clears the undo queue and forces the crash sooner (that would
otherwise
Created attachment 66772
valgrind log with more frames
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/949997
Title:
[Upstream] Ctrl + z and Enter soffice.bin crashed with SIGSEGV
Looks like the SdrUndoInsertObj is the problem, impress creates a derived class
SdrUndoNewObj : public SdrUndoInsertObj from CreateUndoNewObject:
#0 SdrUndoFactory::CreateUndoNewObject (this=0x95c4c08, rObject=...,
bOrdNumDirect=false)
at
I'm just being a lamer - this is easy to reproduce here; I'll poke at
it...
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/785518
Title:
[Upstream] soffice.bin crashed with
I'm suspicious of the: svdundo.cxx /SdrUndoInsertObj::Undo/ method - I
imagine it is removing a different object than the one it is intended to
do (which explains why the main text box in the body disappears, instead
of the header on undo ;-) - an off-by-one as it were. With this
debugging patch:
Created attachment 66772
valgrind log with more frames
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/785518
Title:
[Upstream] soffice.bin crashed with SIGSEGV in
It would be great to have a bibsect investigation on this one - then
again - it is a really early issue:
Crash is [Reproducible] with LibreOffice 3.3.1 RC2 – WIN7 Home Premium
(64bit) German UI [OOO330m19 (build 8 / tag 3.3.1.2)]
That's pretty horrible; so somewhere really early in our launch
Lovely - thanks so much for that Julien - very helpful. You can see the
mess that Java makes in the trace (be nice to turn that off somehow I
guess if it's possible). Sadly the Python garbage collector also
produces a huge mass of false positives as well [ I guess disabling /
deleting *py*.so in
Any chance of a valgrind trace [ the debugging symbols are helpful - but
valgrind should be even sweeter ;-],
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/785518
Title:
Any more joy in finding / splitting out the component parts of this
multi-issue bug ? if not perhaps closing it would provoke filing
separate bugs for any remaining issues ?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to openoffice.org
Created attachment 66770
cleaner log
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/949997
Title:
[Upstream] Ctrl + z and Enter soffice.bin crashed with SIGSEGV in
Created attachment 66782
horrible hack-around ...
This is an horrible band-aid, it stops the crash - but ... it's hard to
live with oneself here. Clearly the arithmetic is going -badly- wrong
here, for some reason - and the code looks glass-fragile all about the
place ;-)
OTOH the band-aid can't
Created attachment 66782
horrible hack-around ...
This is an horrible band-aid, it stops the crash - but ... it's hard to
live with oneself here. Clearly the arithmetic is going -badly- wrong
here, for some reason - and the code looks glass-fragile all about the
place ;-)
OTOH the band-aid can't
Looks like the SdrUndoInsertObj is the problem, impress creates a derived class
SdrUndoNewObj : public SdrUndoInsertObj from CreateUndoNewObject:
#0 SdrUndoFactory::CreateUndoNewObject (this=0x95c4c08, rObject=...,
bOrdNumDirect=false)
at
Lovely - thanks so much for that Julien - very helpful. You can see the
mess that Java makes in the trace (be nice to turn that off somehow I
guess if it's possible). Sadly the Python garbage collector also
produces a huge mass of false positives as well [ I guess disabling /
deleting *py*.so in
I'm suspicious of the: svdundo.cxx /SdrUndoInsertObj::Undo/ method - I
imagine it is removing a different object than the one it is intended to
do (which explains why the main text box in the body disappears, instead
of the header on undo ;-) - an off-by-one as it were. With this
debugging patch:
It would be great to have a bibsect investigation on this one - then
again - it is a really early issue:
Crash is [Reproducible] with LibreOffice 3.3.1 RC2 – WIN7 Home Premium
(64bit) German UI [OOO330m19 (build 8 / tag 3.3.1.2)]
That's pretty horrible; so somewhere really early in our launch
Bjoern - your wiki link fails for me.
The X clipboard system relies on the app owning the selection to provide
the data; if you close the app - that app isn't there; so it will fail.
There are various (varyingly expensive) hacks around this out there in
various desktops; that try to serialise
So - IMHO this is not a libreoffice bug :-) and should be closed
NOTOURBUG ...
Of course, if we can add a configure check to catch systems that are
compiled with an older version of libstdc++ or somesuch that'd be great
- we could prolly compile a small file that did some sizeof() checks in
Radek any thoughts ? seems embarrassingly easy to reproduce - it'd be
wonderful to have a unit test for this as/when we fix it I guess. There
is also a nice stack-trace for windows towards the end of the previous
attachment :-)
--
You received this bug notification because you are a member of
Radek any thoughts ? seems embarrassingly easy to reproduce - it'd be
wonderful to have a unit test for this as/when we fix it I guess. There
is also a nice stack-trace for windows towards the end of the previous
attachment :-)
--
You received this bug notification because you are a member of
three backtraces with debugging symbols from 'g_logv' and (with
export SAL_SYNCHRONIZE=1 # ) gdk_x_error much appreciated.
Thanks :-)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
Gosh; I wonder how many more embarrassing bugs I created with this
nightmarish mapping :-) Thanks guys !
reviewed cherry-picked both commits to -3-5.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
Chopped the range down: it is certainly in the big gtk+ re-factor between:
+ dc4c10d72 - has the crash [!] ...
+ 403608200 - no crash
Will try to peel this back, and hope the commits there build nicely in
isolation.
--
You received this bug notification because you are a member
the deadlock is annoying from the gtk X error handler I guess. I got an
xtrace log thus:
004::0081: 8: Request(23): GetSelectionOwner atom=0x168(CLIPBOARD)
002::1387: Event PropertyNotify(28) window=0x0460044e atom=0x27(WM_NAME)
time=0x0612ed8d state=NewValue(0x00)
004::0081: Event
Looks like the XSetInputFocus call (causing the error):
002::1394: 12: Request(42): SetInputFocus revert-to=Parent(0x02)
focus=0x0460044e time=CurrentTime(0x)
...
002::1394:Error 8=Match: major=42, minor=0, bad=73401422
is this one:
Breakpoint 1, XSetInputFocus (dpy=0x80ff600,
sent to ML for review for libreoffice-3-5 and -3-5-3.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/975503
Title:
Find crashes Libreoffice (GTK)
Status in LibreOffice
Interesting bug - I can't reproduce this at all with SAL_SYNCHRONIZE
set, but without it set it is trivial to reproduce (urgh). Julien - your
traces matches the one I don't get with SAL_SYNC... set :-)
--
You received this bug notification because you are a member of Desktop
Packages, which is
Cor reports some significant slowdowns at first-ever-start it seems
we're doing a load of fsyncs on that code-path (140 or so) - but it'd be
good to get some strace -ttt -f data from him on that.
--
You received this bug notification because you are a member of Desktop
Packages, which is
Can you confirm that turning off use-hardware-acceleration fixes this ? :-)
Sample document cf. bug#46901 shows this clearly:
https://bugs.freedesktop.org/attachment.cgi?id=57920
It is caused by the cairo canvas: in a nutshell :-) should be Linux only
in 3.5.2. Thanks for the nice clean report.
Hi Robert, sorry to hear about your data loss:
I've been using OpenOffice 2.4 for several years with the same NAT, the same
NFS-setup, the same OS and the same odt-files - and I have never had dataloss.
It is worth pointing out that this (missing fsync) is -exactly- the same
in the OpenOffice
pushed fix to master.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/817326
Title:
[Upstream] Previously-saved LibreOffice document lost by power outage
(became 0 bytes long) -
I reproduced the issue here - nasty. Reading the utterly badly designed
GraphicManager for inspiration ... :-)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/157249
Title:
XML delta is:
- draw:image xlink:href=Pictures/24AD475F33B381B9C98F.svm
xlink:type=simple xlink:show=embed xlink:actuate=onLoad/
+ draw:image/
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
with a dbgutil build I get this on autosave:
warn:legacy.osl:32088:1:/data/opt/libreoffice/master/sw/source/core/graphic/ndgrf.cxx:810:
SwGrfNode::_GetStreamForEmbedGrf(..) - embedded graphic file not found!
adding:
--- a/sw/source/core/graphic/ndgrf.cxx
+++ b/sw/source/core/graphic/ndgrf.cxx
@@ -798,6 +798,13 @@ SvStream* SwGrfNode::_GetStreamForEmbedGrf(
}
}
+fprintf( stderr, look for '%s' %d\n,
+ rtl::OUStringToOString( _aStrmName,
vcl/source/gdi/gdimtf.cxx (GDIMetaFile::GetChecksum) was altered:
commit d1da85e8f5d3b6a0c5d1fdcc4fedb0eff5e90b65
Author: ka kai.ahr...@oracle.com
Date: Fri Feb 4 14:49:25 2011 +0100
ka102: SVG import implementation
But - *surely* we can't be fragile on this algorithm changing; it should
The difference between the serialized versions before and after appears
to be an upgrade of the meta-file format:
before:
56 43 4c 4d 54 46 01 00 31 00 00 00 01 00 00 00 |VCLMTF..1...|
0010 01 00 1b 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0020 01 00
Divining a sane and consistent purpose in Michael Brauer's original work
here is somewhat difficult. Suffice it to say that -no-other- image save
goes and tries to rename the stream name that we get the GraphicObject
from.
Then again - other components don't wrap their own versions of SwapIn /
the txtparae.cxx code that does the export does:
// xlink:href
OUString sOrigURL;
rPropSet-getPropertyValue( sGraphicURL ) = sOrigURL;
This calls into
/data/opt/libreoffice/master/sw/source/core/unocore/unoframe.cxx:1402ish that
in a nutshell returns:
With:
--- a/svx/source/xml/xmlgrhlp.cxx
+++ b/svx/source/xml/xmlgrhlp.cxx
@@ -621,6 +621,8 @@ sal_Bool SvXMLGraphicHelper::ImplWriteGraphic( const
::rtl::OUString rPictureSt
}
else if( aGraphic.GetType() == GRAPHIC_GDIMETAFILE )
{
+
Interestingly, if I load and immediately save I get a document with the
images included, -but- this:
look for '24AD475F33B367F3281F.svm' 1
look for [24AD475F33B381B9C98F.svm] 0
look for '24AD475F33B367F3281F.svm' 1
look for
@@ -387,6 +398,9 @@ sal_Bool SwGrfNode::ImportGraphic( SvStream rStrm )
const String aGraphicURL( aGrfObj.GetUserData() );
if( !GraphicFilter::GetGraphicFilter().ImportGraphic( aGraphic,
aGraphicURL, rStrm ) )
{
+fprintf (stderr, Very curious set User Data of '%s' vs
Nice to know this is a re-hash of 2005 - one 'thb' even advised on the
topic back then ;-) I can't reproduce this bug with my moronic patch
applied either. cf: https://issues.apache.org/ooo/show_bug.cgi?id=48434
--
You received this bug notification because you are a member of Desktop
Packages,
patch is:
diff --git a/sw/source/filter/xml/xmltexte.cxx
b/sw/source/filter/xml/xmltexte.cxx
index c62bce3..5c89944 100644
--- a/sw/source/filter/xml/xmltexte.cxx
+++ b/sw/source/filter/xml/xmltexte.cxx
@@ -221,7 +221,9 @@ void SwXMLTextParagraphExport::setTextEmbeddedGraphicURL(
{
By now, I'm highly suspicious of:
void SwXMLTextParagraphExport::setTextEmbeddedGraphicURL(
const Reference XPropertySet rPropSet,
OUString rURL) const
{
if( rURL.isEmpty() )
return;
SwGrfNode *pGrfNd = GetNoTxtNode( rPropSet )-GetGrfNode();
if( !pGrfNd-IsGrfLink()
We have an internal duplicate of this:
https://bugzilla.novell.com/show_bug.cgi?id=681110
And Thorsten is working on it; reproduced in 3.5 and master looks like
cairo using slightly different (and wrong) font substitutions /
settings. Our sample - using Nimbus Roman No9 L is very obviously a
Doing a bit more code reading; it seems that the likeliest place to add
an osl_syncFile - or somesuch UNO call to either the ucb/ or package/
code is the SfxMedium code:
sfx2/source/doc/docfile.cxx (Transfer_Impl)
perhaps this, or hereabouts:
// copy the temporary storage into
A really useful trace - thanks for that ! :-) it seems that a load of
these are related to the flurry of /tmp files that we create (apparently
for no really good reason).
Re-running with:
diff --git a/sal/osl/unx/file.cxx b/sal/osl/unx/file.cxx
index aa6cc26..6b3c56c 100644
---
Using my own patch for a save I got:
Close on '/tmp/lu4uaci5.tmp/lu4uaci9.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uaci9.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacia.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacib.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacib.tmp'
Close on '/tmp/lu4uaci5.tmp/lu4uacib.tmp'
Close on
Created attachment 55644
sal fsync patch ...
Thanks Tristan ! you provoked me into doing something here, and thanks
for the tips. As you say it shouldn't be so hard. I attach a sample
patch to LibreOffice. The only real problem that remains (beyond
removing the debug), is to work out -which- of
Hi Tristan,
FYI, the parse_mounts in your patch won't work for paths containing
whitespace. The whitespace characters are translated into octal escape
sequences in the file. You'd be better off using setmntent and friends,
which handle that for you.
Doh - I should have read your code much
fixed pushed to master and libreoffice-3-5 - will be in 3.5.0RC1.
Thanks all :-)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libreoffice in Ubuntu.
https://bugs.launchpad.net/bugs/916357
Title:
[Upstream] soffice.bin crashed with
After powering up, the GEdit document is intact and contains the latest
content, whereas the LibreOffice document is gone forever.
Thanks for testing. This is as expected, unless we use 'rename' - and
the code needs fixing to do that. *Unfortunately* the code is far worse
than a rats nest here.
Hi Tristan,
I was actually looking into that recently as part of another project
and it's pretty easy. Basically ...
Sounds cool :-) any chance you can knock up a nice fragment of tested C
code that would do this for Linux under MPL/LGPLv3+ that we can couple
up ? We'd want to add that to
This is a tricky area. It is fine to ask people to call fsync like
drunken sailors on ext4 or btrfs - the costs are low; however for ext3
systems an 'fsync' can take many seconds to complete (if one has not
been run recently) during which the entire system is un-responsive to
I/O and the user
Created attachment 54358
comment export patch
I extracted a patch (there was no single commit that added this) for a
potential 3.4.x merge - testing much appreciated, will try to get it
into 3.4.5 RC1.
--
You received this bug notification because you are a member of Desktop
Packages, which is
86 matches
Mail list logo
