Bug 383275 - massif valgrind: m_xarray.c:162 (ensureSpaceXA): Assertion '!xa->arr' failed
Summary: massif valgrind: m_xarray.c:162 (ensureSpaceXA): Assertion '!xa->arr' failed
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: massif (show other bugs)
Version: 3.13.0
Platform: Compiled Sources Linux
: NOR crash
Target Milestone: ---
Assignee: Nicholas Nethercote
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-08 13:22 UTC by Fred M
Modified: 2017-08-17 11:29 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fred M 2017-08-08 13:22:10 UTC
Dear Valgrind, 

By running the valgrind 3.13 on a mipsel chipset. I have the following crash. 
It means to appear on the first "vgdb detailed_snapshot "


 




valgrind: m_xarray.c:162 (ensureSpaceXA): Assertion '!xa->arr' failed.

host stacktrace:
==1517==    at 0x5800AF88: show_sched_status_wrk (m_libcassert.c:355)
==1517==    by 0x5800B170: report_and_quit (m_libcassert.c:426)
==1517==    by 0x5800B374: vgPlain_assert_fail (m_libcassert.c:492)
==1517==    by 0x580366E4: vgPlain_addToXA (m_xarray.c:162)
==1517==    by 0x58039C68: vgPlain_XT_massif_print (m_xtree.c:187)
==1517==    by 0x580029A0: write_snapshots_to_file (ms_main.c:1764)
==1517==    by 0x58002BF4: handle_snapshot_monitor_command (ms_main.c:1815)
==1517==    by 0x58002DC8: handle_gdb_monitor_command.clone.2 (ms_main.c:1884)
==1517==    by 0x58005AC0: ms_handle_client_request (ms_main.c:1636)
==1517==    by 0x5802A360: wrap_tool_handle_client_request (m_tooliface.c:282)
==1517==    by 0x580701C4: handle_gdb_monitor_command (server.c:599)
==1517==    by 0x58070734: handle_query (server.c:777)
==1517==    by 0x58071AAC: server_main (server.c:1225)
==1517==    by 0x58069250: call_gdbserver (m_gdbserver.c:721)
==1517==    by 0x5806A4C8: vgPlain_gdbserver (m_gdbserver.c:788)
==1517==    by 0x58077E44: run_thread_for_a_while (scheduler.c:1025)
==1517==    by 0x5807A178: vgPlain_scheduler (scheduler.c:1344)
==1517==    by 0x58091018: run_a_thread_NORETURN (syswrap-linux.c:103)
==1517==    by 0x580913D4: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:320)
==1517==    by 0x580CE718: ??? (in /usr/lib/valgrind/massif-mips32-linux)

sched status:
  running_tid=2

Thread 1: status = VgTs_WaitSys (lwpid 1517)
==1517==    at 0x56DE37C: __lll_lock_wait (lowlevellock.c:49)
==1517==    by 0x56E213C: pthread_mutex_lock (pthread_mutex_lock.c:87)
==1517==    by 0x6338E78: SefClientLoop_add (libsefclient-loop.c:323)
==1517==    by 0x41E27C: APPINIT_InitStart (init_app.c:790)
==1517==    by 0x420A38: main (main.c:171)

Thread 2: status = VgTs_Runnable (lwpid 1757)
==1517==    at 0x56E37C0: pthread_equal (pthread_equal.c:27)
==1517==    by 0x660C5B4: B_Mutex_Lock (in /usr/lib/libb_os.so)

Thread 3: status = VgTs_WaitSys (lwpid 1758)
==1517==    at 0x64B8A84: __syscall_nanosleep (nanosleep.c:22)
==1517==    by 0x64B8B2C: nanosleep (nanosleep.c:33)
==1517==    by 0x59713B0: TIME_Sleep (time.c:260)
==1517==    by 0x59739A0: TIME_TimerThread (timer.c:114)
==1517==    by 0x56E6584: start_thread (pthread_create.c:297)
==1517==    by 0x56DC0AC: __thread_start (clone.S:146)

Thread 4: status = VgTs_WaitSys (lwpid 1759)
==1517==    at 0x64BA600: ioctl (ioctl.c:24)
==1517==    by 0x48987B4: ioctl (libc_overload.c:325)
==1517==    by 0x66BD950: ??? (in /usr/lib/libnexus.so)

Thread 5: status = VgTs_WaitSys (lwpid 1760)
==1517==    at 0x56DF5E4: pthread_cond_timedwait (pthread_cond_timedwait.c:162)
==1517==    by 0x679F6DC: BKNI_WaitForEvent (in /usr/lib/libnexus.so)

Thread 6: status = VgTs_WaitSys (lwpid 1761)
==1517==    at 0x56DF5E4: pthread_cond_timedwait (pthread_cond_timedwait.c:162)
==1517==    by 0x679F6DC: BKNI_WaitForEvent (in /usr/lib/libnexus.so)


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.

==1517== Reset valgrind output to log (orderly_finish)
readchar: Got EOF
error reading packet




My execution method : 

valgrind --tool=massif --threshold=0.1  --time-unit=ms --vgdb=yes --vgdb-error=0 my_prog &
sleep 20
vgdb run 
sleep 1
vgdb detailed_snapshot massif${DATE_TIME_OF_DAY}_${i}.out






By removing the argument :  --vgdb=yes --vgdb-error=0  , the bug is not seen . 



Regards,
Frédéric
Comment 1 Julian Seward 2017-08-08 13:44:04 UTC
That is very strange.  I have never seen it fail like that before.
Two thoughts:

(1) do you have a consistent, build "from clean" of valgrind?

(2) did it run out of memory?
Comment 2 Philippe Waroquiers 2017-08-08 19:53:50 UTC
Fixed in revision 16469
Bug created by a call to VG_(hintSizeXA) with a 0 size,
which causes m_xarray.c to allocate an array, while 0 elements
should correspond to no array allocated.
Comment 3 Fred M 2017-08-17 11:29:37 UTC
  not reproduced on the rev 16470 .