Hi Stan,
The assertion shown in your dump is no longer in the dyninst master. I encountered that assertion a few month ago and have determined that it is not necessary to assert.
Thanks,
âXiaozhu
> On Mar 27, 2020, at 3:58 PM, Stan Cox <scox@xxxxxxxxxx> wrote:
>
> We are seeing a problem with stapdyn (the systemtap dyninst backend) with dyninst 10.1.0 while setting a probe in firefox. I have attached an admittingly quickly thrown together standalone program that shows the same symptoms.
>> % DYNINSTAPI_RT_LIB=/usr/lib64/dyninst/libdyninstAPI_RT.so /work/scox/dyn/smoke-test/dynamic-static/mutator-pp.x -e /usr/lib64/firefox/firefox -f main -p 27654
>> Instruction jnle 0x9d(%rip)
>> type should be either COND_TAKEN or COND_NOT_TAKEN, but it is 5
>> From 4076d03 to 4076d03
>> mutator-pp.x: /builddir/build/BUILD/dyninst-10.1.0/dyninst-10.1.0/parseAPI/src/BoundFactCalculator.C:379: BoundFact* BoundFactsCalculator::Meet(Dyninst::Node::Ptr): Assertion `0' failed.
>> Aborted (core dumped)
>
> Command line says to add a probe at firefox's main function, pid 27654
>
> Setting DYNINST_DEBUG_PARSING=1 it seems the problems occur after:
> Adding shared object libmozwayland.so, addr range 0x3ed9d000 to 0x3ed9d3b5
>
> This is on Fedora 30:
> Fedora release 30 (Thirty) x86_64
> firefox-74.0-3.fc30.x86_64
> /usr/lib64/firefox/libmozwayland.so
> <mutator-pp.cpp>_______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
|