#Need Help with Seg Fault

36 messages · Page 1 of 1 (latest)

runic tangle
shrewd pythonBOT
#

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.

meager elm
#

If the SEGFAULT is in line 303 then the only explanation for that can really be that current = NULL

#

Which doesn't make sense however as you check for it immediately before

runic tangle
#

Line 302 though
while(current != NULL)

#

I am very confused lol

meager elm
#

Are you sure the error stems from this line? Would you care to share your error message and provide a main function with a MRE (a "minimal reproducible example" [MRE] is a version that has as little as possible going on where the error still occurs).
So if your code fails for a graph with 100 nodes but also for one with just 1, then please share the one with just 1 node.

sand ether
#

are you on linux/mac?

runic tangle
#

And onlinegdb gives the segfault

sand ether
# 
gcc ... -Og -ggdb3 -fsanitize=address,undefined

then run it

meager elm
#

If the error really is in that very line and it isn't NULL then the only other explanation I can think of is current being some garbage value, which then fails when you're trying to dereference that garbage pointer but it isn't NULL which means the check before doesn't fail

runic tangle
#

This is what I got, when I run it using ./bfs test1.txt 1 or some other vertex that I am supposed to test with.

The arguments are supposed to be ./bfs <matrix file> <source vertex>

#

The graph.c file is the one with the segfault

#

i'm not even sure if I implemented this correctly, but I think i did

meager elm
#

Is there a smaller graph for which your code fails? Like, a graph with 10 nodes is quiet big for testing purposes.

sand ether
#

why not try asan? it would cut down the bug hunting time significantly

meager elm
#

yeah, you should definetly do that first

runic tangle
#

That test1.txt is the one that I am given to test with, the other one is 100 nodes.

meager elm
#

Then create one with less nodes on your own

runic tangle
# 
AddressSanitizer:DEADLYSIGNAL
=================================================================
==14926==ERROR: AddressSanitizer: SEGV on unknown address 0x000075000001 (pc 0x5620bba31be6 bp 0x7ffdef2753b0 sp 0x7ffdef275350 T0)
==14926==The signal is caused by a READ memory access.
    #0 0x5620bba31be6 in bfs graph.c:303
    #1 0x5620bba3253b in main main.c:64
    #2 0x7f1caa328d8f  (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f)
    #3 0x7f1caa328e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f)
    #4 0x5620bba31264 in _start (bfs+0x1264)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV graph.c:303 in bfs
==14926==ABORTING
#

https://onlinegdb.com/m1XLtnTtn

GDB online Debugger

Online GDB is online ide with compiler and debugger for C/C++. Code, Compiler, Run, Debug Share code nippets.

#

I tried it with 3 nodes and have the same issue.

meager elm
#

Okay, that's good. Means testing is much easier.
Can you recreate it with 2, 1 or even 0 nodes?

runic tangle
#

Same issue with 2. When I run it with 1 node, it works lol

meager elm
#

Yeah, because with 1 there isn't an edge, but it's good to know that at least that works

#

But yeah, having only 2 nodes makes testing so much easier because you literally just traverse one edge and that's it.

runic tangle
#

Hmm I think I found an issue. When I use 0 for the source vertex it works fine, anything other than that though it fails.

#

i have no idea why it would work for the 0th, but not the rest

meager elm
#

Mind to share the 2 noded graph + settings for which it fails

runic tangle
#

test.txt

2 2 2
0 1
1 0

./bfs test.txt 1

meager elm
#

I can't test it today anymore cause it's quiet late for me (2:30 AM), but maybe with all that information someone else is able to help

runic tangle
runic tangle
#

I fixed my issues. I was supposed to be adding the new node to the 0th index of the 'queue', but instead it was doing it at the source vertex witch isn't always 0. That is why it only worked when it was 0 and had a segfault for everything else.