uwplse / herbgrind

A Valgrind tool for Herbie
GNU General Public License v3.0
90 stars 7 forks source link

Cannot meet types Vt_Double and Vt_NonFloat running python code #58

Closed ggorman closed 4 years ago

ggorman commented 4 years ago

I want to use herbgrind on a c modules that I'm calling from python. It fails within helgrind itself:

==111476== Copyright (C) 2016-2017, and GNU GPL'd, by Alex Sanchez-Stern
==111476== Using Valgrind-3.15.0.GIT and LibVEX; rerun with -h for copyright info
==111476== Command: python3 -m pytest -s --valgrind --tool=herbgrind ./tests/test_gradient.py::TestGradient::test_gradient_checkpointing
==111476== 

Herbgrind: instrument/floattypes.c:1285 (typeMeet): Assertion 'type2 != Vt_NonFloat && type2 != Vt_Single && type2 != Vt_SingleOrNonFloat' failed.
Herbgrind: Cannot meet types Vt_Double and Vt_NonFloat!

host stacktrace:
==111476==    at 0x580399DA: show_sched_status_wrk (m_libcassert.c:369)
==111476==    by 0x58039AF7: report_and_quit (m_libcassert.c:440)
==111476==    by 0x58039C89: vgPlain_assert_fail (m_libcassert.c:506)
==111476==    by 0x5802EF5B: refineTempBlockType (floattypes.c:1283)
==111476==    by 0x58034571: inferTypes (floattypes.c:130)
==111476==    by 0x58024B8D: hg_instrument (instrument.c:63)
==111476==    by 0x580C275F: tool_instrument_then_gdbserver_if_needed (m_translate.c:231)
==111476==    by 0x5813F097: LibVEX_FrontEnd (main_main.c:650)
==111476==    by 0x5813F549: LibVEX_Translate (main_main.c:1185)
==111476==    by 0x580C5391: vgPlain_translate (m_translate.c:1813)
==111476==    by 0x5808E5BB: handle_chain_me (scheduler.c:1167)
==111476==    by 0x5809122F: vgPlain_scheduler (scheduler.c:1516)
==111476==    by 0x580F9EB0: run_a_thread_NORETURN (syswrap-linux.c:103)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 111476)
==111476==    at 0x4EB6038: modf (s_modf.c:50)
==111476==    by 0x582196: _PyLong_FromNbInt (floatobject.c:884)
==111476==    by 0x5A04C7: PyNumber_Long (abstract.c:1333)
==111476==    by 0x5740C2: long_new.lto_priv.330 (longobject.c:4824)
==111476==    by 0x551754: type_call.lto_priv.112 (typeobject.c:895)
==111476==    by 0x5A9EEB: _PyObject_FastCallKeywords (abstract.c:2331)
==111476==    by 0x50A782: call_function.lto_priv.1824 (ceval.c:4875)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x509917: fast_function.lto_priv.2237 (ceval.c:754)
==111476==    by 0x50A64C: call_function.lto_priv.1824 (ceval.c:4872)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x509917: fast_function.lto_priv.2237 (ceval.c:754)
==111476==    by 0x50A64C: call_function.lto_priv.1824 (ceval.c:4872)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x509917: fast_function.lto_priv.2237 (ceval.c:754)
==111476==    by 0x50A64C: call_function.lto_priv.1824 (ceval.c:4872)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x509917: fast_function.lto_priv.2237 (ceval.c:754)
==111476==    by 0x50A64C: call_function.lto_priv.1824 (ceval.c:4872)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x509014: _PyFunction_FastCallDict (ceval.c:754)
==111476==    by 0x5A4D80: _PyObject_FastCallDict (abstract.c:2310)
==111476==    by 0x5A5DBD: _PyObject_CallMethodIdObjArgs (abstract.c:2796)
==111476==    by 0x4F6F4C: PyImport_ImportModuleLevelObject (import.c:1578)
==111476==    by 0x514413: builtin___import__ (bltinmodule.c:238)
==111476==    by 0x50A7F4: call_function.lto_priv.1824 (methodobject.c:231)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x507F23: _PyEval_EvalCodeWithName.lto_priv.1836 (ceval.c:754)
==111476==    by 0x509C4F: fast_function.lto_priv.2237 (ceval.c:4992)
==111476==    by 0x50A64C: call_function.lto_priv.1824 (ceval.c:4872)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x507F23: _PyEval_EvalCodeWithName.lto_priv.1836 (ceval.c:754)
==111476==    by 0x509C4F: fast_function.lto_priv.2237 (ceval.c:4992)
==111476==    by 0x50A64C: call_function.lto_priv.1824 (ceval.c:4872)
==111476==    by 0x50C1F3: _PyEval_EvalFrameDefault (ceval.c:3335)
==111476==    by 0x507F23: _PyEval_EvalCodeWithName.lto_priv.1836 (ceval.c:754)
==111476==    by 0x588F1C: function_call.lto_priv.294 (ceval.c:4187)
==111476==    by 0x59FE1D: PyObject_Call (abstract.c:2261)
==111476==    by 0x6383DA: RunModule (main.c:215)
==111476==    by 0x6390AE: Py_Main (main.c:751)
==111476==    by 0x4B0DBF: main (python.c:69)
client stack range: [0x1FFEFEC000 0x1FFF000FFF] client SP: 0x1FFEFFE8F8
valgrind stack range: [0x1002E8E000 0x1002F8DFFF] top usage: 11528 of 1048576

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.
ggorman commented 4 years ago

I'm running from master HEAD 9f17a88ebec2660a75849a9fbb9e84075307b21c

HazardousPeach commented 4 years ago

This looks like a duplicate of issue #50. But your bringing it up again caused me to take another stab at it, so it should be fixed now by the new commit 4770550 . Hope that helps!