I am running into segmentation fault while trying ...
# pact-beam
p
I am running into segmentation fault while trying to fix the issue - https://github.com/greyorange-labs/pact_erlang/issues/32. This is only happening in linux and not in macos. (Specifically in the call
pactffi_verifier_execute
). The in progress PR is - https://github.com/greyorange-labs/pact_erlang/pull/49 It will be really helpful if anyone knows how to debug/fix this issue. Thanks
✅ 1
y
which version of the ffi are you using? can you try using the latest. or if you are using the latest, move back a version and try? which flavour of linux? musl or glibc?
p
1. current ffi version -
0.4.7
, will try with latest 2. glibc linux
Also i tried using gdb for analysing the dump, the backtrace i got from gdb is the following:
Copy code
#0  _int_malloc(av=0x7c75a0000030, bytes=208) at ./malloc/malloc.c:4122
#1  __GI___libc_malloc(bytes=208) at ./malloc/malloc.c:3336
#2  alloc::vec::Vec<T,A> as core::clone::Clone>::clone()
#3  reqwest::async_impl::request::Request::try_clone()
#4  reqwest::async_impl::request::RequestBuilder::try_clone()
#5  futures_util::stream::fold::Fold::poll()
#6  pact_verifier::utils::with_retries::{{closure}}()
#7  pact_verifier::pact_broker::HALClient::fetch::{{closure}}()
#8  pact_verifier::pact_broker::HALClient::navigate::{{closure}}()
#9  pact_verifier::fetch_pact::{{closure}}::{{closure}}()
#10 tracing::instrument::Instrumented<T>::poll()
#11 futures_util::stream::flatten::Flatten::poll_next()
#12 futures_util::stream::collect::Collect::poll()
#13 pact_verifier::fetch_pacts::{{closure}}::{{closure}}()
#14 pact_verifier::verify_provider_async::{{closure}}::{{closure}}()
#15 tracing::instrument::Instrumented<T>::poll()
#16 tokio::task::task_local::TaskLocalFuture<T,F>::poll()
#17 pact_verifier::verify_provider_async::{{closure}}()
#18 tokio::runtime::context::blocking::BlockingRegionGuard::block_on()
#19 tokio::runtime::context::runtime::enter_runtime()
#20 tokio::runtime::runtime::Runtime::block_on()
#21 pact_ffi::verifier::handle::VerifierHandle::execute()
#22 pact_ffi::error::panic::catch_panic()
#23 pactffi_verifier_execute()
#24 verify_via_broker_direct() at pactffi_nif.c:778
#25 verify_via_broker_direct() at pactffi_nif.c:713
#26 erts_call_dirty_nif() at beam/erl_nif.c:466
#27 erts_dirty_process_main() at beam/beam_common.c:280
#28 sched_dirty_io_thread_func() at beam/erl_process.c:8768
#29 thr_wrapper() at pthread/ethread.c:116
#30 start_thread() at pthread_create.c:447
#31 clone3() at clone3.S:78
y
I can’t see the tests running the on macos action runs here, is that correct? https://github.com/greyorange-labs/pact_erlang/actions/runs/15512562131/job/43675273600 trying locally, is that on your mac or linux? ty
p
Yeah its running on my mac, currently the tests dont run in macos
y
Also i tried using gdb for analysing the dump, the backtrace i got from gdb is the following:
Great stuff, can you isolate to the particular test? and the ffi calls made be in it? We should be able to create a test case repro in rust and test x plat in ci 👍
ahh its the verifier code. Can you say reduce the amount of variables being passed in the example, and reproduce. I see that are broker creds, but also a file_path, which ideally you should only have one or the other. is this for any type of pact spec, transport type, or any? Thx
p
Great stuff, can you isolate to the particular test? and the ffi calls made be in it?
We should be able to create a test case repro in rust and test x plat in ci
Yes, i will try to reproduce this in C without using erlang and report it..
@Yousaf Nabi (pactflow.io) i think you were right, apparently its only happening with my erlang code that interacts with the rust library
I tested my code with just hardcoding it with values and it worked fine without segmentation fault, now I have to debug whats wrong with my NIF code FYI @Srijan Choudhary
Update: when i am trying to verify via broker, getting segmentation fault… not when verifying via local file
@Yousaf Nabi (pactflow.io) is the pactffi library functions thread-safe ?
@Yousaf Nabi (pactflow.io) finally fixed https://github.com/greyorange-labs/pact_erlang/pull/49, tests are passing for both mac and linux machines 😄
hooray 1
y
hmm i’m not sure on thread safety. glad you got it sorted dude, I can’t tell from the PR what the underlying issue was for the seg faults
blob yes 1
p
In the end, I am thinking its because of compatibility issues of pact FFI with the erlang-C interface (or atleast how pact_erlang is using the erlang NIF right now). But I may be wrong …
thinking2 1
@Yousaf Nabi (pactflow.io) Also now the pact_erlang is truly upgraded with a lot of new features, bug fixes and is more stable now with comprehensive documentations about API usage, architecture and how to contribute.
🚀 3
y
Oh amazing! We should look at getting the docs on the main pact docs website, or list erlang so we can advertise the project to others. Have you thought about transferring it into the pact-foundation organisation at some point? We have a #C05HCLA3C93 channel where we hang out if you want to find other pact org members 🙂 I need to take it for a spin, I only had a very cursory look at erlang when going through my FFI adventure. Have you got any sample repos of erlang and pact setup?
In the end, I am thinking its because of compatibility issues of pact FFI with the erlang-C interface (or atleast how pact_erlang is using the erlang NIF right now). But I may be wrong
It’s definitely possible and possibly the most likely, I’ve seen issues in go, where our c interface hasn’t been quite right and it resulted in segfaults. @uglyog do you know about the thread safety guarantees of the FFI, most specifically on the verifier side. Is there any?
p
I need to take it for a spin, I only had a very cursory look at erlang when going through my FFI adventure.
You can look at the test folder, it has examples and you can run the tests after cloning the repo using:
Copy code
make ct
or if rebar3 is installed then just run:
Copy code
rebar3 ct
PS: running the tests requires docker to be installed