Discussion:
valgrind error -- the 'impossible' happened?? (fully updated Arch system)
(too old to reply)
David C. Rankin
2018-08-12 02:14:30 UTC
Permalink
After update to current (as of now linux 4.17.14, and I just tested with
4.17.13 and the error is there too), valgrind fails with an 'impossible' error:

===== error start

$ valgrind ./bin/opendir_readdir_dyn_char_basic
==1196== Memcheck, a memory error detector
==1196== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1196== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1196== Command: ./bin/opendir_readdir_dyn_char_basic
==1196==

valgrind: the 'impossible' happened:
Unsupported arch_prctl option

host stacktrace:
==1196== at 0x580441BA: show_sched_status_wrk (m_libcassert.c:355)
==1196== by 0x580442D4: report_and_quit (m_libcassert.c:426)
==1196== by 0x58044517: panic (m_libcassert.c:502)
==1196== by 0x58044517: vgPlain_core_panic_at (m_libcassert.c:507)
==1196== by 0x5804454A: vgPlain_core_panic (m_libcassert.c:512)
==1196== by 0x580DAE22: vgSysWrap_amd64_linux_sys_arch_prctl_before
(syswrap-amd64-linux.c:286)
==1196== by 0x580A0C23: vgPlain_client_syscall (syswrap-main.c:1857)
==1196== by 0x5809D48A: handle_syscall (scheduler.c:1126)
==1196== by 0x5809EBB6: vgPlain_scheduler (scheduler.c:1443)
==1196== by 0x580AED50: thread_wrapper (syswrap-linux.c:103)
==1196== by 0x580AED50: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 1196)
==1196== at 0x401A1C5: ??? (in /usr/lib/ld-2.28.so)
==1196== by 0x178BFBFE: ???


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.

===== error end

My question is does this look like an arch issue or is it just a kde upstream
issue?

I was answering a question on SO with a simple opendir/readdir of names into a
dynamically allocated pointer-to-pointer-to-char and was showing how to test
with valgrind. To my surprise valgrind croaked on Arch, but ran fine on SuSE
and an old Arch box, so there is something wrong in the current valgrind on Arch.

test source file at
https://stackoverflow.com/questions/51804567/c-writing-readdir-to-char-array-variable/51804959#51804959
(it just reads the contents of the directory given as the first argument ('.'
default) and qsorts and outputs the stored names before freeing the names and
pointers.
--
David C. Rankin, J.D.,P.E.
David C. Rankin
2018-08-12 03:42:52 UTC
Permalink
Post by David C. Rankin
My question is does this look like an arch issue or is it just a kde upstream
issue?
Filed upstream: https://bugs.kde.org/show_bug.cgi?id=397393
--
David C. Rankin, J.D.,P.E.
Eli Schwartz via arch-general
2018-08-12 03:53:13 UTC
Permalink
Post by David C. Rankin
Post by David C. Rankin
My question is does this look like an arch issue or is it just a kde upstream
issue?
Filed upstream: https://bugs.kde.org/show_bug.cgi?id=397393
https://bugs.archlinux.org/task/59551

https://bugs.kde.org/show_bug.cgi?id=396887

If you're going to ask on the mailing list first, could you not then go
submit an upstream bug almost immediately after? I mean, I sort of
assumed the reason you posted to the ML is in order to check whether
this was expected/known, and more critically, it was in the expectation
of getting a reply.

Hence it would be logical to wait for said reply. :)
--
Eli Schwartz
Bug Wrangler and Trusted User
Loading...