Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: lightpush publish segfault #2271

Closed
AlejandroCabeza opened this issue Dec 4, 2023 · 4 comments
Closed

bug: lightpush publish segfault #2271

AlejandroCabeza opened this issue Dec 4, 2023 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@AlejandroCabeza
Copy link
Contributor

Problem

Lightpush's publish triggers a SEGFAULT when sending messages over a specific size.

Impact

...

To reproduce

  1. Instantiate two Switch, one will act as serverSwitch and the other as clientSwitch.
  2. Instantiate a WakuLightPush and a WakuLightPushClient, using the respective switches.
  3. Send a publish request using a WakuMessage that contains a payload with size equal or higher than 1114000B.
  4. This will trigger a SEGFAULT.

Also, you can check out the test case named Valid Paylod Sizes found in waku_lightpush/test_client:198. Remember to update the keyword from xasyncTest to asyncTest, else it will be ignored.

Alternatively, you this PR comment already points to the test.

Expected behavior

Max size is standardised, and max size is gracefully handled.

nwaku version/commit hash

@AlejandroCabeza AlejandroCabeza added the bug Something isn't working label Dec 4, 2023
@Ivansete-status Ivansete-status self-assigned this Jan 8, 2024
@Ivansete-status
Copy link
Collaborator

Thanks for submitting this issue.
This error happens because an exception is raised due to using a too large message:

TRC 2024-01-08 15:06:20.328+01:00 Exception in multistream                   topics="libp2p multistream" tid=194740 file=multistream.nim:210 conn=16U*rE5Nrt:659c015cf2933a85c2c21430 msg="Message exceeds maximum length"

Then, the SIGSEGV is generated in the following:

asyncTeardown:
   await allFutures(clientSwitch.stop(), serverSwitch.stop())

I'm investigating how we could handle exceptions better and why the SIGSEGV is happening. I'm assuming we are trying to stop something that already got stopped due to the exception.

@Ivansete-status
Copy link
Collaborator

The nim-unittest2 bump made in the following PR fixes that segfault issue:
#2353

@Ivansete-status
Copy link
Collaborator

Weekly Update

  • achieved: nim-unittest2 enhancement to prevent segfault when an exception is thrown within the test body and the teardown needs to wait for a libp2p Switch to stop asynchronously.

@Ivansete-status
Copy link
Collaborator

I'm closing because the SEGMENTATION FAULT is not happening any more thanks to the fix mentioned in #2271 (comment).

Steps followed to validate it:

  1. check out to master (commit: 1274b15)
  2. Set the message size to 1114000 in
    fakeWakuMessage(contentTopic = contentTopic, payload = getByteSequence(1024))
  3. Run: nim c -r -d:chronicles_log_level=DEBUG -d:release -d:postgres -d:rln --passL:librln_v0.3.4.a --passL:-lm -d:nimDebugDlOpen ./tests/waku_lightpush/test_client.nim
  4. In this case, the test failed gracefully without a SEGMENTATION FAULT error and clearly stated where it failed: tests/waku_lightpush/test_client.nim(242, 22) publishResponse1.isOk() Exception reading: Stream Remotely Closed! [AssertionDefect]

Thanks so much indeed @AlejandroCabeza for such a wonderful issue description 🥳 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

No branches or pull requests

2 participants