Re: [Libreoffice] Debug compilation fails in sal module
Hello,
With the help of moggi in IRC, i got this :
Reading symbols from
/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/bin/cppunittester...done.
(gdb) run
Starting program:
/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/bin/cppunittester
../../../unxlngi6/lib/libosl_process.so
[Thread debugging using libthread_db enabled]
*** glibc detected *** Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
[New Thread 0xb7bbdb70 (LWP 24474)]
[New Thread 0xb73acb70 (LWP 24475)]
[Thread 0xb73acb70 (LWP 24475) exited]
Program received signal SIGABRT, Aborted.
0xb7fe2424 in __kernel_vsyscall ()
(gdb) bt full
#0 0xb7fe2424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7c34911 in raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar =
pid = -1210712076
selftid = 24471
#2 0xb7c37d42 in abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = 0xb7d5fff4,
sa_sigaction = 0xb7d5fff4}, sa_mask = {__val = {3063940352, 3221204208,
381, 192, 3063939088, 3084255220, 3063939088, 0, 0,
3221204268, 3063949064, 8008, 3063939088, 3084255220, 3063939088,
3063940352, 3221204268, 3083310045, 180, 3063940352,
3084255220, 20, 3221204428, 3083675847, 3063940728, 3063940728, 180,
16384, 3084251200, 0, 3084895800, 27}}, sa_flags = 25,
sa_restorer = 0x17}
sigs = {__val = {32, 0 }}
#3 0xb7c6a9d5 in __libc_message (do_abort=2, fmt=0xb7d3fa70 "*** glibc
detected *** %s: %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
ap =
fd = 7
on_2 =
list =
nlist =
cp =
written = false
#4 0xb7c74ac1 in malloc_printerr (action=, str=0x6
, ptr=0xb7c02cd0) at malloc.c:6283
buf = "b7c02cd0"
cp =
#5 0xb7c76328 in _int_free (av=, p=optimized out>) at malloc.c:4795
size = 0
nextchunk = 0x5f97
nextsize = 3087006400
prevsize =
bck =
fwd =
errstr = 0x6
__func__ = "_int_free"
#6 0xb7c793dd in __libc_free (mem=0xb7c02cd0) at malloc.c:3738
ar_ptr = 0xb7d613c0
p = 0x6
#7 0xb7f1e92a in rtl_freeMemory_SYSTEM (p=0xb7c02cd0) at alloc_global.c:301
No locals.
#8 0xb7f1e9c4 in rtl_freeMemory (p=0xb7c02cd0) at alloc_global.c:371
No locals.
#9 0x0804e1e9 in deallocate (p=0xb7c02cd8, rTraits=...)
at
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx:184
No locals.
#10 0x0804e237 in operator delete (p=0xb7c02cd8)
at
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx:201
No locals.
#11 0x0804d7c3 in __gnu_cxx::new_allocator::deallocate
(this=0xbfffb5ab, __p=0xb7c02cd8 "")
at /usr/include/c++/4.6/ext/new_allocator.h:98
No locals.
#12 0x0804cd9d in std::basic_string,
std::allocator >::_Rep::_M_destroy (this=0xb7c02cd8, __a=...)
at /usr/include/c++/4.6/bits/basic_string.tcc:451
__size = 13
#13 0x0804c78e in std::basic_string,
std::allocator >::_Rep::_M_dispose (this=0xb7c02cd8, __a=...)
at /usr/include/c++/4.6/bits/basic_string.h:244
No locals.
#14 0x0804d5f7 in std::basic_string,
std::allocator >::reserve (this=0xbfffb7c0, __res=17)
at /usr/include/c++/4.6/bits/basic_string.tcc:513
__a = {<__gnu_cxx::new_allocator> = {},
}
__tmp = 0x805cc24 ""
#15 0x0804d721 in std::basic_string,
std::allocator >::append (this=0xbfffb7c0,
__s=0x805aaa8 "SYSTEM_LIBXSLT=NO", __n=17) at
/usr/include/c++/4.6/bits/basic_string.tcc:310
__len = 17
#16 0xb7e082f8 in std::basic_istream >&
std::getline, std::allocator
>(std::basic_istream >&,
std::basic_string, std::allocator >&,
char) ()
from
/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib/libstdc++.so.6
No symbol table info available.
#17 0xb7be4e67 in Test_osl_executeProcess::read_child_environment
(this=0x8053148, env_container=0xbfffb868)
at
/home/maryline/compile-libreoffice/libo/clone/ure/sal/qa/osl/process/osl_process.cxx:480
temp_file_name = {pData = 0x805a918}
file = { >> =
{ >> = { =
{}, _M_tie = 0x0, _M_fill = 0 '\000', _M_fill_init =
false, _M_streambuf = 0xbfffb6b0, _M_ctype = 0xb7e8fc00,
_M_num_put = 0x0, _M_num_get = 0x0}, _vptr.basic_istream
= 0xb7c0258c, _M_gcount = 0},
_M_filebuf = {std::char_traits >> = {_vptr.basic_streambuf = 0xb7c02608,
_M_in_beg = 0x805aaa8 "SYSTEM_LIBXSLT=NO", _M_in_cur =
0x805aaa8 "SYSTEM_LIBXSLT=NO", _M_in_end = 0x805caa7 "",
_M_out_beg = 0x0, _M_out_cur = 0x0, _M_out_end = 0x0,
_M_buf_locale = {static none = 0, static ctype = 1,
static numeric = 2, static collate = 4, static time =
8, static monetary = 16, static messages = 32, static all = 63,
_M_impl = 0xb7e8fa74, static _S_classic = out>, static _S_
Re: [Libreoffice] Debug compilation fails in sal module
Le 27/06/2011 22:47, Markus Mohrhard a écrit :
Hello Julien,
Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
/usr/include/c++/4.6/debug/safe_iterator.h:193:error: attempt to
dereference a past-the-end iterator.
Objects involved in the operation:
iterator "this" @ 0x0xbe966380 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPSsNSt9__cxx19986vectorISsN3rtl9AllocatorISsEENSt7__debug6vectorISsS8_
(mutable iterator);
state = past-the-end;
references sequence with type
`NSt7__debug6vectorISsN3rtl9AllocatorISs' @ 0x0xbe966380
}
this helps a lot. We had a similar situation some days ago. When built
with debug symbols some additional checks are performed to ensure that
iterators are not missused. So it would be a good step if you could
debug the unit test and as soon as you get a SIG ABORT get a backtrace
and post it here or fix the problem. I think that we derefence
vector::end() or something like this.
http://wiki.documentfoundation.org/Development/How_to_debug#Debugging_cppunit_tests
Hello,
I'd like to do this but when I launch "run" in gdb it does the test 1
which is Ok. How to launch the test 2 (I'm a beginner with gdb) ?
Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Hello Julien,
>
> Error: File /home/maryline/compile-**libreoffice/libo/clone/ure/**
> sal/cpprt/operators_new_**delete.cxx, Line 96: operator delete mismatch
> /usr/include/c++/4.6/debug/**safe_iterator.h:193:error: attempt to
> dereference a past-the-end iterator.
>
> Objects involved in the operation:
> iterator "this" @ 0x0xbe966380 {
> type = N11__gnu_debug14_Safe_**iteratorIN9__gnu_cxx17__**
> normal_iteratorIPSsNSt9__**cxx19986vectorISsN3rtl9Allocat**
> orISsEENSt7__**debug6vectorISsS8_ (mutable iterator);
> state = past-the-end;
> references sequence with type
> `NSt7__**debug6vectorISsN3rtl9Allocator**ISs'
> @ 0x0xbe966380
> }
>
this helps a lot. We had a similar situation some days ago. When built with
debug symbols some additional checks are performed to ensure that iterators
are not missused. So it would be a good step if you could debug the unit
test and as soon as you get a SIG ABORT get a backtrace and post it here or
fix the problem. I think that we derefence vector::end() or something like
this.
http://wiki.documentfoundation.org/Development/How_to_debug#Debugging_cppunit_tests
Regards,
Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Le 27/06/2011 22:06, Arnaud Versini a écrit :
Hello,
I've the same problem with this autogen on Ubuntu 10.04 64 too:
--without-junit
--enable-debug
--enable-symbols
We're 3 (3 "declared" :-) ) but for the moment it seems to concern only
Debian/Ubuntu (32 or 64 bits). Have other Linux or BSD distros the same
pb ? What about Mac and Windows ? (Of course, when it's compiled in
debug mode)
Here is 1 more test when I comment out the line 481 from with
qa/osl/process/osl_process.cxx (env_container->push_back(line);)
I get :
==22499==by 0x408756E:
CppUnit::TestRunner::run(CppUnit::TestResult&, std::string const&) (in
/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib/libcppunit-1.12.so.1)
==22499==by 0x804BBBE: sal_main() (cppunittester.cxx:148)
==22499==by 0x804B730: main (cppunittester.cxx:89)
==22499== Address 0x482b850 is 0 bytes inside data symbol
"_ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE"
==22499==
Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
/usr/include/c++/4.6/debug/safe_iterator.h:193:error: attempt to
dereference a past-the-end iterator.
Objects involved in the operation:
iterator "this" @ 0x0xbe966380 {
type =
N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPSsNSt9__cxx19986vectorISsN3rtl9AllocatorISsEENSt7__debug6vectorISsS8_
(mutable iterator);
state = past-the-end;
references sequence with type
`NSt7__debug6vectorISsN3rtl9AllocatorISs' @ 0x0xbe966380
}
==22977==
==22977== HEAP SUMMARY:
==22977== in use at exit: 33,115 bytes in 422 blocks
==22977== total heap usage: 2,179 allocs, 1,747 frees, 240,329 bytes
allocated
==22977==
Memcheck: mc_leakcheck.c:1012 (vgMemCheck_detect_memory_leaks): the
'impossible' happened.
==22977== Block 0x483c000..0x483cfff overlaps with block
0x483c000..0x483c57fThis is usually caused by using
VALGRIND_MALLOCLIKE_BLOCKin an inappropriate way. at 0x3803B51E: ???
(in /usr/lib/valgrind/memcheck-x86-linux)
sched status:
running_tid=2
I attached the file for the details.
Julien.
=
Building module sal
=
Entering /home/maryline/compile-libreoffice/libo/sal/inc
Entering /home/maryline/compile-libreoffice/libo/sal/typesconfig
Entering /home/maryline/compile-libreoffice/libo/sal/osl/all
Entering /home/maryline/compile-libreoffice/libo/sal/rtl/source
--- ALWAYSDBGFILES ---
`../../unxlngi6/slo/debugprint.obj' is up to date
--- ALWAYSDBGFILES OVER ---
Entering /home/maryline/compile-libreoffice/libo/sal/osl/unx
Entering /home/maryline/compile-libreoffice/libo/sal/textenc
Entering /home/maryline/compile-libreoffice/libo/sal/util
Entering /home/maryline/compile-libreoffice/libo/sal/cpprt
Entering /home/maryline/compile-libreoffice/libo/sal/cppunittester
Entering /home/maryline/compile-libreoffice/libo/sal/qa/osl/getsystempathfromfileurl
Entering /home/maryline/compile-libreoffice/libo/sal/qa/rtl/cipher
--
- start unit test #1 on library ../../../unxlngi6/lib/librtl_cipher.so
--
: && LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}} valgrind --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=50 ../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/librtl_cipher.so
==23403== Memcheck, a memory error detector
==23403== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==23403== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==23403== Command: ../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/librtl_cipher.so
==23403==
OK (24)
==23403==
==23403== HEAP SUMMARY:
==23403== in use at exit: 302 bytes in 4 blocks
==23403== total heap usage: 1,221 allocs, 1,217 frees, 284,869 bytes allocated
==23403==
==23403== 8 bytes in 1 blocks are still reachable in loss record 1 of 4
==23403==at 0x4025018: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23403==by 0x4103906: rtl_allocateMemory_SYSTEM (alloc_global.c:294)
==23403==by 0x4103976: rtl_allocateMemory (alloc_global.c:329)
==23403==by 0x41039E8: rtl_allocateZeroMemory (alloc_global.c:383)
==23403==by 0x40DD85B: osl_setCommandArgs (process_impl.cxx:242)
==23403==by 0x40DE097: sal_detail_initialize (salinit.cxx:39)
==23403==by 0x804B72B: main (cppunittester.cxx:89)
==23403==
==23403== 20 bytes in 1 blocks are still reachable in loss record 2 of 4
==23403==at 0x4023796: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==23403==by 0x4403105: _dlerror_run (dlerror.c:142)
==23403==by 0x4402B40: dlopen@@GLIBC_2.1 (dlopen.c:88)
==23403==by 0x408AD70: CppUnit::DynamicLibraryManager::doLoadLibrary(std::string
Re: [Libreoffice] Debug compilation fails in sal module
Hello, I've the same problem with this autogen on Ubuntu 10.04 64 too: --without-junit --enable-debug --enable-symbols 2011/6/23 serv serva > > De: Caolán McNamara > > Objet: Re: [Libreoffice] Debug compilation fails in sal module > > À: "Julien Nabet" > > Cc: libreoffice@lists.freedesktop.org > > Date: Jeudi 23 juin 2011, 12h52 > > On Thu, 2011-06-23 at 11:42 +0100, > > Caolán McNamara wrote: > > > On Wed, 2011-06-22 at 21:52 +0200, Julien Nabet > > wrote: > > > > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > > > > On Tue, 2011-06-21 at 23:18 +0200, Julien > > Nabet wrote: > > > > >> I'm completely stucked, could it be a > > bug in one of the C++ libraries of > > > > >> Debian testing ? > > > ... > > > > I'm going to take a look at it and hope to find > > something. > > > > Some more thoughts, this is the debug build, this may be > > triggered by > > _GLIBCXX_DEBUG in solenv, removing those and rm -rf > > sal/unxlng* and a > > rebuild could test that theory. > > Your theory was right, I commented out all that concerns _GLIBCXX_DEBUG in > : > - sal/inc/unxgcc.mk > - sal/gbuild/platform/unxgcc.mk > > Then remove sal/unxlng* and build again. > Everything is ok. > > Julien. > ___ > LibreOffice mailing list > LibreOffice@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/libreoffice > -- Arnaud Versini ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
> De: Caolán McNamara > Objet: Re: [Libreoffice] Debug compilation fails in sal module > À: "Julien Nabet" > Cc: libreoffice@lists.freedesktop.org > Date: Jeudi 23 juin 2011, 12h52 > On Thu, 2011-06-23 at 11:42 +0100, > Caolán McNamara wrote: > > On Wed, 2011-06-22 at 21:52 +0200, Julien Nabet > wrote: > > > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > > > On Tue, 2011-06-21 at 23:18 +0200, Julien > Nabet wrote: > > > >> I'm completely stucked, could it be a > bug in one of the C++ libraries of > > > >> Debian testing ? > > ... > > > I'm going to take a look at it and hope to find > something. > > Some more thoughts, this is the debug build, this may be > triggered by > _GLIBCXX_DEBUG in solenv, removing those and rm -rf > sal/unxlng* and a > rebuild could test that theory. Your theory was right, I commented out all that concerns _GLIBCXX_DEBUG in : - sal/inc/unxgcc.mk - sal/gbuild/platform/unxgcc.mk Then remove sal/unxlng* and build again. Everything is ok. Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
> De: Caolán McNamara > Objet: Re: [Libreoffice] Debug compilation fails in sal module > À: "Julien Nabet" > Cc: libreoffice@lists.freedesktop.org > Date: Jeudi 23 juin 2011, 12h42 > On Wed, 2011-06-22 at 21:52 +0200, > Julien Nabet wrote: > > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > > On Tue, 2011-06-21 at 23:18 +0200, Julien Nabet > wrote: > > >> I'm completely stucked, could it be a bug in > one of the C++ libraries of > > >> Debian testing ? > ... ... > I wonder. Can you give me the output of... > > md5sum solver/350/unxlngi6/lib/libstdc++.so.6 > and > md5sum /usr/lib/libstdc++.so.6 to make sure they match. Here they are : $ md5sum solver/350/unxlngi6/lib/libstdc++.so.6 6d2c6b2aa1716b21f033f6bc590e5488 solver/350/unxlngi6/lib/libstdc++.so.6 $ md5sum /usr/lib/libstdc++.so.6 6d2c6b2aa1716b21f033f6bc590e5488 /usr/lib/libstdc++.so.6 So they're exactly the same. I'm going to take a look for the debug part later. Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Thu, 2011-06-23 at 13:06 +0100, serv serva wrote: > I'm curious to know if I'm the only one to have this problem with debug > compilation. No. I'm getting it as well now. I wasn't when you first mentioned it but I've done a g pull -r since then. For reference, I'm on Ubuntu 11.04 (Natty) 64-bit. Just checked the md5sums as Caolan suggested. They match. I'll try the _GLIBCXX_DEBUG thing later today if I get time. Nigel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Thu, 2011-06-23 at 13:06 +0100, serv serva wrote: > I'm curious to know if I'm the only one to have this problem with debug > compilation. It appears so, I suspect something like http://lists.apple.com/archives/cocoa-dev/2009/Sep/msg01199.html C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
--- En date de : Jeu 23.6.11, Caolán McNamara a écrit : > De: Caolán McNamara > Objet: Re: [Libreoffice] Debug compilation fails in sal module > À: "Julien Nabet" > Cc: libreoffice@lists.freedesktop.org > Date: Jeudi 23 juin 2011, 12h42 > On Wed, 2011-06-22 at 21:52 +0200, > Julien Nabet wrote: > > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > > On Tue, 2011-06-21 at 23:18 +0200, Julien Nabet > wrote: > > >> I'm completely stucked, could it be a bug in > one of the C++ libraries of > > >> Debian testing ? > ... > > I'm going to take a look at it and hope to find > something. > > Address 0x482bcd0 is 0 bytes inside data symbol > "_ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE" > > c++filt > _ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE > > guard variable for std::num_get std::istreambuf_iterator std::char_traits > >::id > > so that's completely nuts I think, so... > > I wonder. Can you give me the output of... > > md5sum solver/350/unxlngi6/lib/libstdc++.so.6 > and > md5sum /usr/lib/libstdc++.so.6 to make sure they match. > I saw this output for Valgrind and I thought about comparing osl_process.cxx in unx part with equivalent Windows part. I remarked that in unx part string_container_t was a vector of std::string + something. In Windows, it was a list of OUString + something For the md5, I'll do that as soon as I get home. I'm curious to know if I'm the only one to have this problem with debug compilation. About rm -rf sal/unxlng, I did that everytime since it's quick to recompile this whole part. But about solenv Debug, I'll take a look. Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Thu, 2011-06-23 at 11:42 +0100, Caolán McNamara wrote: > On Wed, 2011-06-22 at 21:52 +0200, Julien Nabet wrote: > > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > > On Tue, 2011-06-21 at 23:18 +0200, Julien Nabet wrote: > > >> I'm completely stucked, could it be a bug in one of the C++ libraries of > > >> Debian testing ? > ... > > I'm going to take a look at it and hope to find something. Some more thoughts, this is the debug build, this may be triggered by _GLIBCXX_DEBUG in solenv, removing those and rm -rf sal/unxlng* and a rebuild could test that theory. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Wed, 2011-06-22 at 21:52 +0200, Julien Nabet wrote: > Le 22/06/2011 13:55, Caolán McNamara a écrit : > > On Tue, 2011-06-21 at 23:18 +0200, Julien Nabet wrote: > >> I'm completely stucked, could it be a bug in one of the C++ libraries of > >> Debian testing ? ... > I'm going to take a look at it and hope to find something. Address 0x482bcd0 is 0 bytes inside data symbol "_ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE" c++filt _ZGVNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE guard variable for std::num_get > >::id so that's completely nuts I think, so... I wonder. Can you give me the output of... md5sum solver/350/unxlngi6/lib/libstdc++.so.6 and md5sum /usr/lib/libstdc++.so.6 to make sure they match. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Tue, 2011-06-21 at 23:18 +0200, Julien Nabet wrote: > I'm completely stucked, could it be a bug in one of the C++ libraries of > Debian testing ? I suppose, have you tried installing valgrind, and use export VALGRIND=memcheck and do "build" in sal to see if valgrind says anything interesting. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Le 20/06/2011 21:42, Julien Nabet a écrit : Le 20/06/2011 21:32, Julien Nabet a écrit : Le 20/06/2011 15:19, Caolán McNamara a écrit : On Mon, 2011-06-20 at 10:08 +0100, serv serva wrote: It happens each time. I don't know what element has triggered this. I tried gdb but when I runned it, it makes the first which is ok. I don't know how to go to this specific test. Could you see the patch in the other thread "interesting difference in..." and see if it makes a difference to this problem as well. C. Hello, I just git updated and read that you had commited and pushed your patch. So I did a "rm -rf unxlng*" in sal and build again. I've still got an error but it's slightly different, here is what I get : Making:libosl_process.so Making:all_qa_osl_process.dpslo ... I used "export DEBUGCPPUNIT=TRUE" and runned again a build in the sal directory. I attached a zip which contains console logs and gdb trace log from sal/qa/process. Hope it can give hints. I tried to follow this link : http://www.codeguru.com/forum/archive/index.php/t-314870.html but nothing special. I'm completely stucked, could it be a bug in one of the C++ libraries of Debian testing ? Julien. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Mon, 2011-06-20 at 21:42 +0200, Julien Nabet wrote: > I used "export DEBUGCPPUNIT=TRUE" and runned again a build in the sal > directory. > I attached a zip which contains console logs and gdb trace log from > sal/qa/process. > Hope it can give hints. Well, that's odd, that says that std::line is freeing some memory when getting resized in std::getline in... std::string line; while (std::getline(file, line, '\0')) env_container->push_back(line); and crashing there, but there's apparently nothing wrong with that on the face of it anyway. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
Le 20/06/2011 15:19, Caolán McNamara a écrit :
On Mon, 2011-06-20 at 10:08 +0100, serv serva wrote:
It happens each time. I don't know what element has triggered this.
I tried gdb but when I runned it, it makes the first which is ok. I don't know
how to go to this specific test.
Could you see the patch in the other thread "interesting difference
in..." and see if it makes a difference to this problem as well.
C.
Hello,
I just git updated and read that you had commited and pushed your patch.
So I did a "rm -rf unxlng*" in sal and build again.
I've still got an error but it's slightly different, here is what I get :
Making:libosl_process.so
Making:all_qa_osl_process.dpslo
--
- start unit test #1 on library ../../../unxlngi6/lib/libosl_Thread.so
--
: &&
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_Thread.so
OK (6)
--
- start unit test #2 on library ../../../unxlngi6/lib/libosl_process.so
--
: &&
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_process.so
*** glibc detected *** ../../../unxlngi6/bin/cppunittester: free():
invalid pointer: 0xb74facd0Error: File
/home/maryline/compile-libreoffice/libo/clone/ure/sal/cpprt/operators_new_delete.cxx,
Line 96: operator delete mismatch
/bin/bash: line 1: 15149 Aborted
LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_process.so
dmake: Error code 134, while making 'test2'
We clearly see in the logs that there's an invalid pointer.
Julien.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Mon, 2011-06-20 at 10:08 +0100, serv serva wrote: > It happens each time. I don't know what element has triggered this. > I tried gdb but when I runned it, it makes the first which is ok. I don't > know how to go to this specific test. Could you see the patch in the other thread "interesting difference in..." and see if it makes a difference to this problem as well. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
--- En date de : Lun 20.6.11, Caolán McNamara a écrit :
> De: Caolán McNamara
> Objet: Re: [Libreoffice] Debug compilation fails in sal module
> À: "Julien Nabet"
> Cc: libreoffice@lists.freedesktop.org
> Date: Lundi 20 juin 2011, 10h57
> On Sun, 2011-06-19 at 12:04 +0200,
> Julien Nabet wrote:
> >
> LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
>
> > ../../../unxlngi6/bin/cppunittester
> ../../../unxlngi6/lib/libosl_process.so
>
> > I took a look at the git history of sal module and
> found nothing special.
>
>
> Does it happen every time, or some times. I think there's
> a
> race/threading bug in there that doesn't get triggered
> everytime.
Hello,
It happens each time. I don't know what element has triggered this.
I tried gdb but when I runned it, it makes the first which is ok. I don't know
how to go to this specific test.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] Debug compilation fails in sal module
On Sun, 2011-06-19 at 12:04 +0200, Julien Nabet wrote:
> LD_LIBRARY_PATH=/home/maryline/compile-libreoffice/libo/clone/ure/sal/unxlngi6/lib:/home/maryline/compile-libreoffice/libo/solver/350/unxlngi6/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
>
> ../../../unxlngi6/bin/cppunittester ../../../unxlngi6/lib/libosl_process.so
> I took a look at the git history of sal module and found nothing special.
Does it happen every time, or some times. I think there's a
race/threading bug in there that doesn't get triggered everytime.
C.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
