> I understand that this PYTHON is used only during the build. I added it
> because I had a failed build with something related to Python (couldn't
> find some library) in the past. The Python there is the official release
> from www.python.org, by the way, the same one that LO uses internally.
>
Tor Lillqvist wrote:
> > ./autogen.sh PYTHON=/usr/local/bin/python3.3
> > --with-ant-home=/opt/local/share/java/apache-ant/
>
> We need to change configure.ac so that it makes sure that an attempt at
> using some 3rd-party
> Python fails already when running autogen.sh. IMHO, we don't wan
Christian Lohmaier wrote:
> On Mon, Apr 6, 2015 at 6:00 PM, Piet van Oostrum wrote:
> > Sorry that the previous mail was sent as a reply to an unrelated message.
> > Please disregard and use this one.
> >
> > I got the dreaded DeploymentException again. This time I compiled LO
> > 4.4.2.2
Hi Piet,
On Tue, Apr 07, 2015 at 02:48:32PM +0200, Piet van Oostrum
wrote:
> The build completed but there was one failing unit test. A different one than
> mentioned in the bug report.
>
> crop-pixel.docx,292
> File tested,Execution Time (ms)
> crop-pixel.docx,/Users/piet/Downloads/LibreOffic
Stephan Bergmann wrote:
> On 04/06/2015 06:00 PM, Piet van Oostrum wrote:
> > Sorry that the previous mail was sent as a reply to an unrelated message.
> > Please disregard and use this one.
> >
> > I got the dreaded DeploymentException again. This time I compiled LO
> > 4.4.2.2 from source
> ./autogen.sh PYTHON=/usr/local/bin/python3.3
--with-ant-home=/opt/local/share/java/apache-ant/
We need to change configure.ac so that it makes sure that an attempt at
using some 3rd-party Python fails already when running autogen.sh. IMHO, we
don't want to support that. (Unless Piet volunteers t
On Mon, Apr 6, 2015 at 6:00 PM, Piet van Oostrum wrote:
> Sorry that the previous mail was sent as a reply to an unrelated message.
> Please disregard and use this one.
>
> I got the dreaded DeploymentException again. This time I compiled LO 4.4.2.2
> from sources. The reason I do this is because
On 04/06/2015 06:00 PM, Piet van Oostrum wrote:
Sorry that the previous mail was sent as a reply to an unrelated message.
Please disregard and use this one.
I got the dreaded DeploymentException again. This time I compiled LO 4.4.2.2
from sources. The reason I do this is because I want to apply
On 31.03.2015 15:08, Michael Stahl wrote:
> On 28.03.2015 21:52, Piet van Oostrum wrote:
>> > Now when I do this with a Writer document:
>> >
>> > textdoc =
>> smgr.createInstanceWithContext("com.sun.star.text.TextDocument", context)
>> >
>> > LibreOffice crashes with a segmentation fault.
Michael Stahl wrote:
> On 28.03.2015 21:52, Piet van Oostrum wrote:
> > > Now when I do this with a Writer document:
> > >
> > > textdoc =
> > smgr.createInstanceWithContext("com.sun.star.text.TextDocument", context)
> > >
> > > LibreOffice crashes with a segmentation fault.
>
On 28.03.2015 21:52, Piet van Oostrum wrote:
> Piet van Oostrum wrote:
>
> > I am currently experimenting with programming LibreOffice through
> Python/UNO.
> > One thing I tried is to create a document, not with the
> > loadComponentFromURL call from the desktop, but the route via the
> > XL
Piet van Oostrum wrote:
> I am currently experimenting with programming LibreOffice through Python/UNO.
> One thing I tried is to create a document, not with the
> loadComponentFromURL call from the desktop, but the route via the
> XLoadable interface,
[snip]
> Now when I do this with a Wri
Piet,
first i alayw provide some information when storing not a empty array a
you did
Thiscomponent.storeToURL( ConvertToURL(sfile), Array(
MakePropertyValue("FilterName", "writer8", "ReadOnly", "False" ))
and i allways do convertToURL(myURL) to been sure it's a correct URL
On 11/06/2012 10:35 AM, Ulrich Kitzinger wrote:
at the City of Munich we have an Office extension, the WollMux
(http://www.wollmux.net/). And we have a little problem: After
installing the WollMux via the Extension Manager, Libre Office crashes
reliably when you start Writer (not LibreOffice), an
> The pool allocator stuff which G_SLICE disables has memcheck markup in
> it already, it already gets used if the valgrind headers are available
> at build-time so in theory we could just stuff the header in
> unconditionally and always build with memcheck-detectable memory pool
> foo.
In practi
On Wednesday, June 22, 2011, Michael Meeks wrote:
> But a single method:
>
> bool running_under_valgrind (void);
> or
> bool running_under_memcheck (void);
>
> so we can switch our allocation semantics auto-magically.
>
> Julian - we have lots of complex stuff; how
On Wed, 2011-06-22 at 11:44 +0100, Michael Meeks wrote:
> Which makes me wonder ... should we not include the BSD licensed,
> valgrind remote header into our build, and use the magic traps to detect
> it ?
The pool allocator stuff which G_SLICE disables has memcheck markup in
it already, it
On Wed, Jun 22, 2011 at 5:44 AM, Michael Meeks wrote:
>
> On Wed, 2011-06-22 at 11:03 +0100, Caolán McNamara wrote:
>> When you valgrind manually you definitely do
>> export G_SLICE=always-malloc to disable the internal allocator ?
>
> Which makes me wonder ... should we not include the BSD
On 22/06/11 11:03, Caolán McNamara wrote:
On Tue, 2011-06-21 at 17:43 +0100, Noel Power wrote:
well it doesn't crash for me ( even worse it doesn't crash without the
patch either ) and even worse still valgrind doesn't even complain.
When you valgrind manually you definitely do
export G_SLICE=a
Yes I used --enable-debug. And the problem disappeared with my patch and a
clean rebuild. It seems that I had some problems with delivering damke build
modules.
2011/6/22 Noel Power
> On 22/06/11 10:23, Noel Power wrote:
>
>> On 22/06/11 10:19, Noel Power wrote:
>>
>>> still I see with the debug
On Tue, 2011-06-21 at 17:43 +0100, Noel Power wrote:
> well it doesn't crash for me ( even worse it doesn't crash without the
> patch either ) and even worse still valgrind doesn't even complain.
When you valgrind manually you definitely do
export G_SLICE=always-malloc to disable the internal a
On 22/06/11 10:23, Noel Power wrote:
On 22/06/11 10:19, Noel Power wrote:
still I see with the debug build that I did that I can't reproduce
this, seems that for me _GLIBCXX_DEBUG isn't set. Just from my future
reference what did you pass to configure ? ( I just passed the
--enable-debug )
s
On 22/06/11 10:19, Noel Power wrote:
still I see with the debug build that I did that I can't reproduce
this, seems that for me _GLIBCXX_DEBUG isn't set. Just from my future
reference what did you pass to configure ? ( I just passed the
--enable-debug )
seems I did something wrong here, I don
On 21/06/11 23:44, Markus Mohrhard wrote:
Ok I looked into the corresponding gcc stl function and it seems that
the debug function checks if the iterator is incrementable. I haven't
checked the macro that performs this check but the iterator might be
marked as invalid after an element has been
Not surprisingly, this was apparently once again the result of a List ->
std::vector replacement. From June 16. So it seems "we" aren't getting any
better in doing these.
I really don't see any way to solve this except to go through all commits that
do such "cleanups" and figure out how to actu
Ok I looked into the corresponding gcc stl function and it seems that the
debug function checks if the iterator is incrementable. I haven't checked
the macro that performs this check but the iterator might be marked as
invalid after an element has been erased. So this crash will only happen
during
On 21/06/11 18:52, Markus Mohrhard wrote:
I did a debug build. And I had some stl debug symbols in my backtrace
so it might be that perhaps the compiler won't optimize this out.
I attached the backtrace.
print it shows: it = {<__gnu_debug::_Safe_iterator_base> =
{_M_sequence = 0x29e3678, _M_v
I did a debug build. And I had some stl debug symbols in my backtrace so it
might be that perhaps the compiler won't optimize this out.
I attached the backtrace.
print it shows: it = {<__gnu_debug::_Safe_iterator_base> = {_M_sequence =
0x29e3678, _M_version = 0, _M_prior = 0x0, _M_next = 0x0}, _M
On 21/06/11 15:17, Markus Mohrhard wrote:
Hello Noel, all,
I have attached a test document and a diff. I don't understand why
this still crashs calc even if there is nothing anymore that can
create any problems.
well it doesn't crash for me ( even worse it doesn't crash without the
patch eith
On Thu, 2011-05-26 at 22:16 -0700, Joseph Powers wrote:
> Ok, I reverted my changes and Option->Path works now...
:-)
> I'll need to review what when wrong and try for a version 2 patch later.
Yes - it was fairly unclear to me too - but I didn't spend so long
looking into it. Ap
Ok, I reverted my changes and Option->Path works now...
I'll need to review what when wrong and try for a version 2 patch later.
Joe P.
On May 26, 2011, at 6:02 AM, Michael Meeks wrote:
> Hi there,
>
> Tools->Options - press arrow down a few times to the print options:
> Bang ... valgrin
I'm showing:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0004
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libtlmxi.dylib 0x014eb11a String::String
On Wed, 2011-04-27 at 19:55 -0400, Peter Teeson wrote:
> Both OpenOffice 3.3.0 and LibreOffice 3.3.2 exhibit this behaviour.
> Steps to reproduce:
> (0) Launch either app
> (1) New spreadsheet
> (2) Format/Cells...
> Crash!
This will almost certainly turn out to be triggered by a specific fo
Michael Meeks wrote:
> On Wed, 2011-04-27 at 19:55 -0400, Peter Teeson wrote:
> > As a retired Mac developer I would like to help track down this
> > reproducible bug.
>
> Great stuff :-) nasty that it affects the stable release - it would be
> great to have you digging into that.
>
Hi Pete
Hi Peter,
On Wed, 2011-04-27 at 19:55 -0400, Peter Teeson wrote:
> As a retired Mac developer I would like to help track down this
> reproducible bug.
Great stuff :-) nasty that it affects the stable release - it would be
great to have you digging into that.
> Whom should I contact? Do I
Thanks for the answer. I now used gdb to locate the segfault, and
found it to happen when ScViewFunc called ScRangeList.front() with an
empty range list, which resulted in a segfault while trying to
retrieve the first element of the list. I have prepared the attached
patch, adding a check for empty
Hi Soeren,
On Tue, 2011-01-25 at 23:13 +0100, Soeren Moeller wrote:
> Hi
>
> I just noticed a bug in master (pull about 1h ago):
> When I in calc press the sum button (shaped like a sigma), then calc
> crashes instantly and without any message. This seems to happen only
> when calc doesn't guess
Chris i'm on a mac running 10.6.5 and cant replicate the issue. also i
know a few weeks ago there was an update for java. do you have all
updates installed for java?
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedeskto
Chris Makepeace wrote:
> Libre Office (current) and OOo (3.2.1) is repeatedly crashing as I go into
> Preferences (Mac language for 'Options').
>
> The system console reports that the crash is related to JavaNativeFoundation
> and the crash log makes no mention of Java but does spend 771 lines
> r
On Fri, 2010-11-19 at 18:12 +, Andrew wrote:
> Hmm, that crashed LibreOffice, and then when I started it again, the
> Document Recovery Tool opened. At the last step, where it says 'Click
> next to open the Error Reporting Tool', I clicked next, but the error
> reporting tool didn't open and i
On 19/11/10 17:39, Michael Meeks wrote:
>
> On Fri, 2010-11-19 at 16:33 +, Andrew wrote:
>> I might have a go if you can give me some way to invoke the crash report
>> detector - so I can see what it looks like.
>
> We need more crashes ! [ "there's an app for that" ;-]. You could (I
>
On Fri, 2010-11-19 at 16:33 +, Andrew wrote:
> I might have a go if you can give me some way to invoke the crash report
> detector - so I can see what it looks like.
We need more crashes ! [ "there's an app for that" ;-]. You could (I
guess) try killing soffice.bin thusly:
pk
On 19/11/10 08:21, Thorsten Behrens wrote:
> Jean-Baptiste Faure wrote:
>> Yesterday I got the crash report in LibO after a test of docking the
>> navigator on the right edge of the LibO window. It contained a link to
>> the privacy policy of Oracle.
>>
>> I did not sent the crash report because it
Le 19/11/2010 09:21, Thorsten Behrens a écrit :
> Jean-Baptiste Faure wrote:
>> Yesterday I got the crash report in LibO after a test of docking the
>> navigator on the right edge of the LibO window. It contained a link to
>> the privacy policy of Oracle.
>>
>> I did not sent the crash report becau
Jean-Baptiste Faure wrote:
> Yesterday I got the crash report in LibO after a test of docking the
> navigator on the right edge of the LibO window. It contained a link to
> the privacy policy of Oracle.
>
> I did not sent the crash report because it was no clear for me who is
> the recipient of th
On Tue, 2010-11-16 at 23:29 -0500, Andriy Rysin wrote:
> There's a OOo bug
> http://www.openoffice.org/issues/show_bug.cgi?id=84159 which describes
> a crash happening if document has too much formatting. This also
> applies to LO. It usually happens at closing the document but can also
> happen at
46 matches
Mail list logo
