Re: Random *** stack smashing detected *** message
On 09/05/2018 05:30 PM, Richard W.M. Jones wrote: It gives an odd error (see attached). Is that a bug in eu-stack? It seems that all debuginfo was successfully loaded. I don't see a way to debug this further. If it does not reproduce, I'm inclined to blame it on faulty memory. 8-p Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, 2018-09-05 at 18:04 +0100, Richard W.M. Jones wrote: > On Wed, Sep 05, 2018 at 06:40:47PM +0200, Mark Wielaard wrote: > > We don't know the exact release version, but given the build-id > > [0aea4b30d53d7cc6386f1773a8dc8972793def1a] we should be able to > > match it against an older glibc package. > > Here are all the versions of glibc installed on that machine as far > back as the DNF logs go (which is only a couple of months > unfortunately): > > 2.26.9000-41.fc28 > 2.26.9000-48.fc28 > 2.27.9000-28.fc29 > 2.27.9000-35.fc29 > 2.28-6.fc29 > 2.28.9000-4.fc30 > 2.28-9.fc29 > > Of those only 2.27.9000-35.fc29 contains the build ID. > > That's the glibc-debuginfo that I already have installed (I realize > now why my previous email was wrong - the file is called > /usr/lib/debug/.build-id/0a/ea4b30d53d7cc6386f1773a8dc8972793def1a). > > However it still can't find a symbol matching the address, so I guess > we're out of luck. It might just be that the stack got corrupted, so the addresses don't really make sense. Note however that libc.so is a shared library that may be mapped everywhere. If you look at the partial backtrace that eu- stack generated you see: #0 0x7f13c71ce46f - /usr/lib64/libc-2.27.9000.so (deleted) [0aea4b30d53d7cc6386f1773a8dc8972793def1a]@0x7f13c7197000+0x3746f #1 0x7f13c72a4435 - 1 - /usr/lib64/libc-2.27.9000.so (deleted) [0aea4b30d53d7cc6386f1773a8dc8972793def1a]@0x7f13c7197000+0x10d434 Which says the file with build-id 0aea... was mapped at 0x7f13c7197000 so the offsets from the start of the mapping are 0x3746f and 0x10d434. Normally you would then try to match these against the .symtab in the .debug file. But glibc is special and keeps the symtab in the main file... So if you really want to hunt this down you might have to get the main glibc 2.27.9000-35.fc29 rpm and rpm2cpio it somewhere. Then try to extract the symbol table from that .../usr/lib64/libc-2.27.9000.so (eu- readelf -s). Or since you have the debugfile already try searching the .debuginfo with eu-readelf --debug-dump=info and look for a low_pc with 03746[a-f] to see if there is a construct that matches. Sorry this is all a bit messy (and possibly unresolvable if the stack was just corrupted). Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, Sep 05, 2018 at 06:04:27PM +0100, Richard W.M. Jones wrote: > On Wed, Sep 05, 2018 at 06:40:47PM +0200, Mark Wielaard wrote: > > We don't know the exact release version, but given the build-id > > [0aea4b30d53d7cc6386f1773a8dc8972793def1a] we should be able to > > match it against an older glibc package. > > Here are all the versions of glibc installed on that machine as far > back as the DNF logs go (which is only a couple of months > unfortunately): > > 2.26.9000-41.fc28 > 2.26.9000-48.fc28 > 2.27.9000-28.fc29 > 2.27.9000-35.fc29 > 2.28-6.fc29 > 2.28.9000-4.fc30 > 2.28-9.fc29 > > Of those only 2.27.9000-35.fc29 contains the build ID. > > That's the glibc-debuginfo that I already have installed (I realize > now why my previous email was wrong - the file is called > /usr/lib/debug/.build-id/0a/ea4b30d53d7cc6386f1773a8dc8972793def1a). > > However it still can't find a symbol matching the address, so I guess > we're out of luck. Do you have both these: glibc-debuginfo.x86_64 glibc-debuginfo-common.x86_64 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, Sep 05, 2018 at 06:40:47PM +0200, Mark Wielaard wrote: > We don't know the exact release version, but given the build-id > [0aea4b30d53d7cc6386f1773a8dc8972793def1a] we should be able to > match it against an older glibc package. Here are all the versions of glibc installed on that machine as far back as the DNF logs go (which is only a couple of months unfortunately): 2.26.9000-41.fc28 2.26.9000-48.fc28 2.27.9000-28.fc29 2.27.9000-35.fc29 2.28-6.fc29 2.28.9000-4.fc30 2.28-9.fc29 Of those only 2.27.9000-35.fc29 contains the build ID. That's the glibc-debuginfo that I already have installed (I realize now why my previous email was wrong - the file is called /usr/lib/debug/.build-id/0a/ea4b30d53d7cc6386f1773a8dc8972793def1a). However it still can't find a symbol matching the address, so I guess we're out of luck. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, Sep 05, 2018 at 06:40:47PM +0200, Mark Wielaard wrote: > On Wed, Sep 05, 2018 at 04:30:59PM +0100, Richard W.M. Jones wrote: > > On Wed, Sep 05, 2018 at 05:23:45PM +0200, Mark Wielaard wrote: > > > On Wed, 2018-09-05 at 13:59 +0100, Richard W.M. Jones wrote: > > > > On Wed, Sep 05, 2018 at 02:27:44PM +0200, Florian Weimer wrote: > > > > > But which one? For 2.28-9.fc29 or 2.27.9000-35.fc29? If GDB can't > > > > > find the build ID, I'd suggest try the other version as well. > > > > > > > > Oh I see, good point. I only had debuginfo installed for the > > > > new version. > > > > > > > > I've now installed every debuginfo related to the coredump, > > > > and the old glibc debuginfo, but still: > > > > > > > > Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): > > > > #0 0x7f13c71ce46f in ?? () > > > > #1 0x in ?? () > > > > > > > > So, I don't know ... > > > > > > You could try eu-stack, with -l it should print out a memory map which > > > might give you a hint about the modules/build-ids. > > > $ eu-stack -v -l -b -m --core core.file > > > > It gives an odd error (see attached). Is that a bug in eu-stack? > > It just says it also cannot unwind the stack, the stack might > just be corrupt, or because of the missing libraries it might not > have enough information or a wrong view of what is mapped where. > > But we do now know that the process is bash-4.4.23-2 running against > the old, no longer installed, libc-2.27.9000.so. > > We don't know the exact release version, but given the build-id > [0aea4b30d53d7cc6386f1773a8dc8972793def1a] we should be able to > match it against an older glibc package. Would I expect some file or symlink matching *0aea4b30d53d7cc6386f1773a8dc8972793def1a* to exist in the filesystem, given I have what I think is the correct glibc debuginfo to be installed? Because it does *not* exist: $ find /usr -name '*0aea4b30d53d7cc6386f1773a8dc8972793def1a*' find: ‘/usr/share/polkit-1/rules.d’: Permission denied find: ‘/usr/share/selinux/targeted/default/active’: Permission denied find: ‘/usr/libexec/initscripts/legacy-actions/auditd’: Permission denied Does this indicate that I have the wrong glibc debuginfo installed? $ rpm -q glibc-debuginfo glibc-debuginfo-2.27.9000-35.fc29.x86_64 $ rpm -ql glibc-debuginfo | grep 0aea4b30d53d7cc [no output] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, Sep 05, 2018 at 04:30:59PM +0100, Richard W.M. Jones wrote: > On Wed, Sep 05, 2018 at 05:23:45PM +0200, Mark Wielaard wrote: > > On Wed, 2018-09-05 at 13:59 +0100, Richard W.M. Jones wrote: > > > On Wed, Sep 05, 2018 at 02:27:44PM +0200, Florian Weimer wrote: > > > > But which one? For 2.28-9.fc29 or 2.27.9000-35.fc29? If GDB can't > > > > find the build ID, I'd suggest try the other version as well. > > > > > > Oh I see, good point. I only had debuginfo installed for the > > > new version. > > > > > > I've now installed every debuginfo related to the coredump, > > > and the old glibc debuginfo, but still: > > > > > > Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): > > > #0 0x7f13c71ce46f in ?? () > > > #1 0x in ?? () > > > > > > So, I don't know ... > > > > You could try eu-stack, with -l it should print out a memory map which > > might give you a hint about the modules/build-ids. > > $ eu-stack -v -l -b -m --core core.file > > It gives an odd error (see attached). Is that a bug in eu-stack? It just says it also cannot unwind the stack, the stack might just be corrupt, or because of the missing libraries it might not have enough information or a wrong view of what is mapped where. But we do now know that the process is bash-4.4.23-2 running against the old, no longer installed, libc-2.27.9000.so. We don't know the exact release version, but given the build-id [0aea4b30d53d7cc6386f1773a8dc8972793def1a] we should be able to match it against an older glibc package. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, Sep 05, 2018 at 05:23:45PM +0200, Mark Wielaard wrote: > On Wed, 2018-09-05 at 13:59 +0100, Richard W.M. Jones wrote: > > On Wed, Sep 05, 2018 at 02:27:44PM +0200, Florian Weimer wrote: > > > But which one? For 2.28-9.fc29 or 2.27.9000-35.fc29? If GDB can't > > > find the build ID, I'd suggest try the other version as well. > > > > Oh I see, good point. I only had debuginfo installed for the > > new version. > > > > I've now installed every debuginfo related to the coredump, > > and the old glibc debuginfo, but still: > > > > Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): > > #0 0x7f13c71ce46f in ?? () > > #1 0x in ?? () > > > > So, I don't know ... > > You could try eu-stack, with -l it should print out a memory map which > might give you a hint about the modules/build-ids. > $ eu-stack -v -l -b -m --core core.file It gives an odd error (see attached). Is that a bug in eu-stack? However if I'm understanding the output correctly then it does indicate that the addresses are located in the pre-upgraded glibc. > Or try eu-unstrip -n --core core.file Also attached. Note that I have these debuginfo packages installed: $ rpm -qa | grep glibc.*debug glibc-debuginfo-2.27.9000-35.fc29.x86_64 glibc-debuginfo-common-2.27.9000-35.fc29.x86_64 However there is no debugsource for glibc. Is that right? Rich. > Which should do the same and list what it knows about the > files/modules/build-ids in the core file. > > Cheers, > > Mark -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v PID 31373 - core module memory map 0x5600d2445000-0x5600d2762000 bash [c062328c3bffc26e3bf771ca755f3f7be9cbd1ef] - /usr/lib/debug/usr/bin/bash-4.4.23-2.fc29.x86_64.debug 0x7f13b99f8000-0x7f13b9c1 libgcc_s-8-20180626.so.1 [9c93906baa7ef8956717ac6f154a9eb5343266ba] 0x7f13ba4cd000-0x7f13ba6df000 libnss_files-2.27.9000.so (deleted) [b5cd6746d5fe86fdc41428903aba10ed591a6c5f] 0x7f13c7197000-0x7f13c7559000 libc-2.27.9000.so (deleted) [0aea4b30d53d7cc6386f1773a8dc8972793def1a] 0x7f13c7559000-0x7f13c775d000 libdl-2.27.9000.so (deleted) [d70abe37cab2d70829500d8d978dde5e2d0f61a0] 0x7f13c798a000-0x7f13c7bb4000 ld-linux-x86-64.so.2 [a45582478b0565ee95f5c30b9aa1ca756377] 0x7ffe30963000-0x7ffe30964000 linux-vdso.so.1 [bb9230e93a76a60897d80f0e426d3ef6ec4a5e8c] - 0x7f13b90f7000-0x7f13b9376228 libpcre2-8.so.0 [547f82f93ed78712131e4aa327c7bfa3489a6aee] /lib64/libpcre2-8.so.0 /usr/lib/debug/usr/lib64/libpcre2-8.so.0.7.0-10.31-7.fc29.x86_64.debug 0x7f13b9377000-0x7f13b959f5f0 libselinux.so.1 [b3f9d896f17b1d069676f334e103e42a3ce55435] /lib64/libselinux.so.1 /usr/lib/debug/usr/lib64/libselinux.so.1-2.8-2.fc29.x86_64.debug 0x7f13b95a-0x7f13b97a6010 libuuid.so.1 [17fc933808ffd57410b880604f793be8c8b3f5ed] /lib64/libuuid.so.1 /usr/lib/debug/usr/lib64/libuuid.so.1.3.0-2.32-6.fc29.x86_64.debug 0x7f13b97a7000-0x7f13b99f7700 libblkid.so.1 [203b20f30ece28c8a94a53ab0958450a1fee3f05] /lib64/libblkid.so.1 /usr/lib/debug/usr/lib64/libblkid.so.1.1.0-2.32-6.fc29.x86_64.debug 0x7f13b9c1-0x7f13b9e69520 libmount.so.1 [8cd20ddf0160249eb679193616c77dd02a430b45] /lib64/libmount.so.1 /usr/lib/debug/usr/lib64/libmount.so.1.1.0-2.32-6.fc29.x86_64.debug 0x7f13b9e6a000-0x7f13ba06e138 libcap.so.2 [b3438067c70d4daddfdd74e47dee5014744c6dc9] /lib64/libcap.so.2 /usr/lib/debug/usr/lib64/libcap.so.2.25-2.25-11.fc29.x86_64.debug 0x7f13ba06f000-0x7f13ba2c30d8 libnss_systemd.so.2 [d936045b5a287e8be94109974725bdfe17367960] /lib64/libnss_systemd.so.2 /usr/lib/debug/usr/lib64/libnss_systemd.so.2-239-2.fc29.x86_64.debug 0x7f13ba2c4000-0x7f13ba4cc310 libnss_sss.so.2 [307f04eaa3c880bff241bcd9795f2271c5ae452d] /lib64/libnss_sss.so.2 /usr/lib/debug/usr/lib64/libnss_sss.so.2-1.16.2-5.fc29.x86_64.debug 0x7f13c775d000-0x7f13c7989980 libtinfo.so.6 [d407283b9f5f4ba9c3f455bb7749783f05c5d473] /lib64/libtinfo.so.6 /usr/lib/debug/usr/lib64/libtinfo.so.6.1-6.1-5.20180224.fc29.x86_64.debug PID 31373 - core TID 31373: #0 0x7f13c71ce46f - /usr/lib64/libc-2.27.9000.so (deleted) [0aea4b30d53d7cc6386f1773a8dc8972793def1a]@0x7f13c7197000+0x3746f #1 0x7f13c72a4435 - 1 - /usr/lib64/libc-2.27.9000.so (deleted) [0aea4b30d53d7cc6386f1773a8dc8972793def1a]@0x7f13c7197000+0x10d434 eu-stack: dwfl_thread_getframes tid 31373 at 0x7f13c72a4434 in /usr/lib64/libc-2.27.9000.so (deleted): invalid operation 0x5600d2445000+0x31d000 c062328c3bffc26e3bf771ca755f3f7be9cbd1ef@0x5600d24452b4 . /usr/lib/debug/usr/bin/bash-4.4.23-2.fc29.x86_64.debug /usr/bin/bash 0x7f13b99f8000+0x218000
Re: Random *** stack smashing detected *** message
On Wed, 2018-09-05 at 13:59 +0100, Richard W.M. Jones wrote: > On Wed, Sep 05, 2018 at 02:27:44PM +0200, Florian Weimer wrote: > > But which one? For 2.28-9.fc29 or 2.27.9000-35.fc29? If GDB can't > > find the build ID, I'd suggest try the other version as well. > > Oh I see, good point. I only had debuginfo installed for the > new version. > > I've now installed every debuginfo related to the coredump, > and the old glibc debuginfo, but still: > > Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): > #0 0x7f13c71ce46f in ?? () > #1 0x in ?? () > > So, I don't know ... You could try eu-stack, with -l it should print out a memory map which might give you a hint about the modules/build-ids. $ eu-stack -v -l -b -m --core core.file Or try eu-unstrip -n --core core.file Which should do the same and list what it knows about the files/modules/build-ids in the core file. Cheers, Mark ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, Sep 05, 2018 at 02:27:44PM +0200, Florian Weimer wrote: > On 09/05/2018 02:22 PM, Richard W.M. Jones wrote: > >On Wed, Sep 05, 2018 at 02:10:15PM +0200, Florian Weimer wrote: > >>On 09/05/2018 02:07 PM, Richard W.M. Jones wrote: > >>>I just hit a weird bug. When I typed: > >>> > >>> $ sudo dnf update --best /mntsc > >>> > >>>bash exited (and with it, my ssh session) saying: > >>> > >>> *** stack smashing detected ***: terminated > >>> Connection to srv closed. > >>> > >>>This was after updating to glibc-2.28-9.fc29.x86_64. > >>>Unfortunately I cannot seem to reproduce it on demand. > >> > >>That looks rather unusual. From which version did you update? > > > >I think from glibc 2.27.9000-35.fc29 -> 2.28-9.fc29. > > There might have been an ld.so ABI change, so processes launched > with the old ld.so might file when they dlopen something which > depends on the new libpthread, for example. > > >>>The good news is that a coredump was collected. The bad news is > >>>it looks pretty useless: > >>> > >>> Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): > >>> #0 0x7f13c71ce46f in ?? () > >>> #1 0x in ?? () > >>> > >>>Before I file a bug, what component should be used? What other > >>>information is useful? Why would this happen just from keyboard > >>>input? > >> > >>Please try get a backtrace with debuginfo installed. Thanks. > > > >Yeah unfortunately that is with debuginfo :-( > > But which one? For 2.28-9.fc29 or 2.27.9000-35.fc29? If GDB can't > find the build ID, I'd suggest try the other version as well. Oh I see, good point. I only had debuginfo installed for the new version. I've now installed every debuginfo related to the coredump, and the old glibc debuginfo, but still: Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): #0 0x7f13c71ce46f in ?? () #1 0x in ?? () So, I don't know ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On 09/05/2018 02:22 PM, Richard W.M. Jones wrote: On Wed, Sep 05, 2018 at 02:10:15PM +0200, Florian Weimer wrote: On 09/05/2018 02:07 PM, Richard W.M. Jones wrote: I just hit a weird bug. When I typed: $ sudo dnf update --best /mntsc bash exited (and with it, my ssh session) saying: *** stack smashing detected ***: terminated Connection to srv closed. This was after updating to glibc-2.28-9.fc29.x86_64. Unfortunately I cannot seem to reproduce it on demand. That looks rather unusual. From which version did you update? I think from glibc 2.27.9000-35.fc29 -> 2.28-9.fc29. There might have been an ld.so ABI change, so processes launched with the old ld.so might file when they dlopen something which depends on the new libpthread, for example. The good news is that a coredump was collected. The bad news is it looks pretty useless: Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): #0 0x7f13c71ce46f in ?? () #1 0x in ?? () Before I file a bug, what component should be used? What other information is useful? Why would this happen just from keyboard input? Please try get a backtrace with debuginfo installed. Thanks. Yeah unfortunately that is with debuginfo :-( But which one? For 2.28-9.fc29 or 2.27.9000-35.fc29? If GDB can't find the build ID, I'd suggest try the other version as well. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On Wed, Sep 05, 2018 at 02:10:15PM +0200, Florian Weimer wrote: > On 09/05/2018 02:07 PM, Richard W.M. Jones wrote: > >I just hit a weird bug. When I typed: > > > > $ sudo dnf update --best /mntsc > > > >bash exited (and with it, my ssh session) saying: > > > > *** stack smashing detected ***: terminated > > Connection to srv closed. > > > >This was after updating to glibc-2.28-9.fc29.x86_64. > >Unfortunately I cannot seem to reproduce it on demand. > > That looks rather unusual. From which version did you update? I think from glibc 2.27.9000-35.fc29 -> 2.28-9.fc29. > >The good news is that a coredump was collected. The bad news is > >it looks pretty useless: > > > > Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): > > #0 0x7f13c71ce46f in ?? () > > #1 0x in ?? () > > > >Before I file a bug, what component should be used? What other > >information is useful? Why would this happen just from keyboard > >input? > > Please try get a backtrace with debuginfo installed. Thanks. Yeah unfortunately that is with debuginfo :-( The correct component is glibc? Unfortunately without a decent stack trace and with no effective way to reproduce it, I'm not sure a bug is going to help. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Random *** stack smashing detected *** message
On 09/05/2018 02:07 PM, Richard W.M. Jones wrote: I just hit a weird bug. When I typed: $ sudo dnf update --best /mntsc bash exited (and with it, my ssh session) saying: *** stack smashing detected ***: terminated Connection to srv closed. This was after updating to glibc-2.28-9.fc29.x86_64. Unfortunately I cannot seem to reproduce it on demand. That looks rather unusual. From which version did you update? The good news is that a coredump was collected. The bad news is it looks pretty useless: Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): #0 0x7f13c71ce46f in ?? () #1 0x in ?? () Before I file a bug, what component should be used? What other information is useful? Why would this happen just from keyboard input? Please try get a backtrace with debuginfo installed. Thanks. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Random *** stack smashing detected *** message
I just hit a weird bug. When I typed: $ sudo dnf update --best /mntsc bash exited (and with it, my ssh session) saying: *** stack smashing detected ***: terminated Connection to srv closed. This was after updating to glibc-2.28-9.fc29.x86_64. Unfortunately I cannot seem to reproduce it on demand. The good news is that a coredump was collected. The bad news is it looks pretty useless: Thread 1 (Thread 0x7f13c7b7d740 (LWP 31373)): #0 0x7f13c71ce46f in ?? () #1 0x in ?? () Before I file a bug, what component should be used? What other information is useful? Why would this happen just from keyboard input? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
