Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

run fail on glibc-2.28 #139

Closed
neochapay opened this issue Oct 17, 2018 · 2 comments
Closed

run fail on glibc-2.28 #139

neochapay opened this issue Oct 17, 2018 · 2 comments

Comments

@neochapay
Copy link

neochapay commented Oct 17, 2018

I use selfbuilded zypper and libzepp with glibc-2.28 and gcc-6.4.0

When i run zypper i got

double free or corruption (out)
Aborted (core dumped)

In gdb:

Program received signal SIGABRT, Aborted.
0xf7fd3059 in __kernel_vsyscall ()
(gdb) bt
#0  0xf7fd3059 in __kernel_vsyscall ()
#1  0xf75b0e20 in __libc_signal_restore_set (set=0xffffd220) at ../sysdeps/unix/sysv/linux/internal-signals.h:84
#2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:48
#3  0xf75b2007 in __GI_abort () at abort.c:79
#4  0xf75f541c in __libc_message (action=do_abort, fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:181
#5  0xf75fcecd in malloc_printerr (str=str@entry=0xf771f23c "double free or corruption (out)") at malloc.c:5336
#6  0xf75ff383 in _int_free (av=0xf77797c0 <main_arena>, p=0x8212228 <vtable for __cxxabiv1::__vmi_class_type_info+36>, have_lock=<optimized out>) at malloc.c:4264
#7  0xf780586a in operator delete(void*) () from /usr/lib/libstdc++.so.6
#8  0xf7b5cdd1 in deallocate (this=<optimized out>, __p=<optimized out>) at /usr/include/c++/6.4.0/ext/new_allocator.h:110
#9  _M_destroy (__a=<synthetic pointer>, this=<optimized out>) at /usr/include/c++/6.4.0/bits/basic_string.tcc:889
#10 _M_dispose (__a=<synthetic pointer>, this=<optimized out>) at /usr/include/c++/6.4.0/bits/basic_string.h:2780
#11 std::string::reserve (this=0x821326c <SourceDownloadOptions::_defaultDirectory>, __res=33) at /usr/include/c++/6.4.0/bits/basic_string.tcc:951
#12 0xf7dc9755 in zypp::filesystem::Pathname::_assign (this=0x821326c <SourceDownloadOptions::_defaultDirectory>, name_r="/var/cache/zypper/source-download")
    at /usr/src/debug/libzypp-17.3.1-1.3.10.i386/zypp/Pathname.cc:37
#13 0x080796c5 in Pathname (name_r=0x81d6b60 "/var/cache/zypper/source-download", this=0x821326c <SourceDownloadOptions::_defaultDirectory>) at /usr/include/zypp/Pathname.h:56
#14 __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
    at /usr/src/debug/zypper-1.11.22+master.20180625103952.3.g3375f81-1.2.15.i386/src/source-download.cc:26
#15 _GLOBAL__sub_I__ZN21SourceDownloadOptions17_defaultDirectoryE () at /usr/src/debug/zypper-1.11.22+master.20180625103952.3.g3375f81-1.2.15.i386/src/source-download.cc:484
#16 0x081bb81b in __libc_csu_init ()
#17 0xf7592464 in __libc_start_main (main=0x8077d20 <main(int, char**)>, argc=2, argv=0xffffd744, init=0x81bb7d0 <__libc_csu_init>, fini=0x81bb830 <__libc_csu_fini>, 
    rtld_fini=0xf7fe5430 <_dl_fini>, stack_end=0xffffd73c) at ../csu/libc-start.c:264
#18 0x08079d21 in _start ()
@bzeller
Copy link
Contributor

bzeller commented Oct 18, 2018

I tried to compile the most recent libzypp/zypper inside your nemo SDK chroot, the same crash happens there. However I can not reproduce the crash with the same code on my local machine. So most likely your libstdc++ or libc is the issue here.

@mlandres
Copy link
Member

More than a year old. No more similar reports/issues and TW is meanwhile on glibc-2.29. I think we can close it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants