Getting Segmentation Fault errors after increasing number of users

71 views
Skip to first unread message

Ali HosseinAliPour

unread,
Mar 26, 2023, 9:20:12 AM3/26/23
to ns-3-users

Hello everyone.

I have implemented the OSPF routing protocol in NS3.

For a small number of users (e.g., 4 users) I have no problem and everything is well.

But, when I increase the number of users (e.g. 8 users), I continue to get Segmentation Fault errors (<Signals.SIGSEGV: 11>).

Using gdb, the code is interrupted in lines that do not have any problems.

I have figured out that this problem might be related to the fact that the buffer of the C++ compiler is full. (When I remove some unimportant variables, the error moves to other lines).

 Hence, I cannot exactly determine which line is wrong, and after implementing a change (for example using "std::cout " to print a variable) the error moves to another line (especially, to the lines that I am trying to assign a new value to a variable) . That is why I didn't share my code here.

If anyone has any advice on how to prevent this kind of problem, I would appreciate it.

Thanks in advance.

Tom Henderson

unread,
Mar 26, 2023, 11:51:26 AM3/26/23
to ns-3-...@googlegroups.com
I do not understand your comment that the C++ compiler buffer is full.  You are getting a runtime error-- the code has already been compiled.

You should build your code in 'debug' mode when using gdb; use of the default (which has some optimizations) or optimized mode can sometimes hide the problems.  When your code breaks due to a segmentation fault, you need to step upwards in the backtrace until you find the variable that is the problem (usually it is a dereference of a null pointer).

This page may help:

- Tom
--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/0701201a-9465-48bb-84ec-af5268e2aeaan%40googlegroups.com.


Gabriel Ferreira

unread,
Mar 26, 2023, 6:25:42 PM3/26/23
to ns-3-users
You have made a memory management mistake somewhere. Use valgrind or sanitizers to discover where. 

Tommaso Pecorella

unread,
Mar 26, 2023, 9:47:43 PM3/26/23
to ns-3-users
Also, try using "debug" configuration mode ("ns3 configure --d debug") instead of "default", because optimisation might result in the debugger highlighting the wrong line.

Ali HosseinAliPour

unread,
Mar 27, 2023, 5:46:30 AM3/27/23
to ns-3-users
First, I want to say thank you for your great help and advice.

But, dear Mr. Tommaso Pecorella after I used  "ns3 configure -d debug"  , everything became surprisingly good, and now my code works perfectly without any errors.

Hence, I am excited to know if there is a technical reason for this phenomenon. Should I be still concern about memory leak?

Because, before using NS3, I used "valgrind", and it realized there are some memory leaks in my code. But, now even "valgrind" says everything is perfect and I have no error.

Thanks again for your time.

Gabriel Ferreira

unread,
Mar 27, 2023, 8:17:17 AM3/27/23
to ns-3-users
Which means you probably have memory corruption AND undefined 
behavior somewhere. 
The optimization removed part of the program assuming it wasunreachable,
leaving the wrong code to be executed. 

Here's a presentation on undefined behavior. 

Tommaso Pecorella

unread,
Mar 27, 2023, 10:58:12 PM3/27/23
to ns-3-users
Unfortunately I agree with Gabriel. Unfortunately, this kind of problems are very nasty and hard to correct.
I'd suggest to run the code though clang's sanification and behaviour check, they usually are able to spot undefined behaviour code.


Reply all
Reply to author
Forward
0 new messages