I attach the bt, if someone is interested I can print the variables of a
specific frame.
make CppunitTest_sw_globalfilter
(lldb) breakpoint set --file
/Volumes/Master/lo/core/sw/qa/extras/globalfilter/globalfilter.cxx --line
663
(lldb) run
(lldb) breakpoint set --file
Le 02/06/2015 08:39, Stephan Bergmann a écrit :
Hi Stephan,
Robert, please monitor the health of your tb, and if it starts to
systematically fail, do something about it. In this particular case,
please debug into the cause of that DisposedException.
Nothing to do with :
On 06/02/2015 09:48 AM, Alex Thurgood wrote:
Le 02/06/2015 08:39, Stephan Bergmann a écrit :
Robert, please monitor the health of your tb, and if it starts to
systematically fail, do something about it. In this particular case,
please debug into the cause of that DisposedException.
Nothing
On 06/02/2015 11:36 AM, Robert Antoni Buj i Gelonch wrote:
(lldb) run
Just doing run in the debugger is not helpful here; rather, you need
to break where the loadComponentFromURL call is made and step into that
and hope you find the reason why it returns null before you get lost.
(Or,
By running
/Volumes/Master/lo/core/instdir/LibreOfficeDev.app/Contents/MacOS/soffice
/Volumes/Master/lo/core//sw/qa/extras/globalfilter/data/skipimages.docx,
EMF+ image is not displayed, however LO is able to open skipimages.docx.
make CppunitTest_sw_globalfilter
Le 02/06/2015 10:04, Stephan Bergmann a écrit :
And right, on closer inspection of the CppunitTest output, the
DisposedException (during tearDown) might be a red herring, and the
truly relevant part is why loading
sw/qa/extras/globalfilter/data/skipimages.docx fails in the first place.
*
so this smells like the issue discussed in
https://bugs.documentfoundation.org/show_bug.cgi?id=90502 CRASH -
failed assertion in unittest sw_globalfilter in master build OSX, and the
working hypothesis would be that your tb's failure symptoms are the
non-debug manifestation of the same
Hey,
On Tue, Jun 2, 2015 at 10:46 PM, Robert Antoni Buj i Gelonch
robert@gmail.com wrote:
Hi, I can move forward until aEnv.startLoading()
Process 13147 stopped
* thread #1: tid = 0x2c50ef, 0x0001173583dc
Hi, I can move forward until aEnv.startLoading()
Process 13147 stopped
* thread #1: tid = 0x2c50ef, 0x0001173583dc
libfwklo.dylib`framework::LoadEnv::loadComponentFromURL(xLoader=0x7fff5fbf3758,
xContext=0x0001087913d0, sURL=0x7fff5fbf4b00,
sTarget=0x7fff5fbf40b8, nFlags=0,
Thanks Markus,
I saw that n=9223372036854755805 before to fail. Now, I'm going to examine
where it comes from.
* thread #1: tid = 0x2c7680, 0x0001064bb54a
libvcllo.dylib`ImplLogicToPixel(n=9223372036854755805, nDPI=72, nMapNum=1,
nMapDenom=1600, nThres=64051194700380381) + 170 at
Robert Antoni wrote
OK, I'm going to build a debug build from scratch.
Just for information, you may encounter
https://bugs.documentfoundation.org/show_bug.cgi?id=90502 which has
prevented me to build a full enable-dbg-util build on MacOs since weeks.
However, if it's the case, you may also
OK, I'm going to build a debug build from scratch.
make distclean
./autogen.sh --enable-debug \
--with-vendor=Robert Buj Gelonch \
--with-macosx-sdk=10.10 \
--with-macosx-version-min-required=10.10 \
--disable-gtk \
--enable-firebird-sdbc \
--enable-extension-integration \
--enable-ext-nlpsolver
On 06/02/2015 03:01 PM, Robert Antoni Buj i Gelonch wrote:
Assertion failed: (nMapNum == 0 || std::abs(n)
std::numeric_limitslong::max() / nMapNum / nDPI), function
ImplLogicToPixel, file
/Volumes/Master/lo/core/vcl/source/outdev/map.cxx, line 382.
so this smells like the issue discussed in
Ok, thanks for the info.
2015-06-02 14:06 GMT+02:00 julien2412 serval2...@yahoo.fr:
Robert Antoni wrote
OK, I'm going to build a debug build from scratch.
Just for information, you may encounter
https://bugs.documentfoundation.org/show_bug.cgi?id=90502 which has
prevented me to build a
On 05/29/2015 06:33 PM, Julien Nabet wrote:
On 29/05/2015 14:22, Robert Antoni Buj i Gelonch wrote:
..
I think that the packaging issue, it's related with the system cache
which is periodically purged by OS, or something similar.
I didn't do anything to solve booth issues:
I executed make
Robert Antoni wrote
I shut down the tb61 yesterday, I'm going to put it up and running again.
...
Hi Robert,
Your TB is now up and ok. Good thing! : )
Just for curiosity, did you change something on it? (hardware/soft, runned a
make clean ...)
Indeed, there was this pb:
ERROR: ERROR: Found an
Hi Julien,
I think that the packaging issue, it's related with the system cache which
is periodically purged by OS, or something similar.
I didn't do anything to solve booth issues:
I executed make distclean. Next, I rebooted the machine, and I executed
these commands:
diskutil erasevolume HFS+
On 29/05/2015 14:22, Robert Antoni Buj i Gelonch wrote:
..
I think that the packaging issue, it's related with the system
cache which is periodically purged by OS, or something similar.
I didn't do anything to solve booth issues:
I executed make distclean. Next, I rebooted the machine, and I
Hi,
I shut down the tb61 yesterday, I'm going to put it up and running again.
If there is someone who wants that I shut it down, please reply this thread.
Regards,
Robert
2015-05-28 19:09 GMT+02:00 julien2412 serval2...@yahoo.fr:
Hi,
I just wanted to communicate about the patch
19 matches
Mail list logo
