Skip to content
This repository has been archived by the owner on Jan 15, 2023. It is now read-only.

Occasional segfaults and spotted some buffer overflows #4

Open
mpentler opened this issue May 27, 2018 · 4 comments
Open

Occasional segfaults and spotted some buffer overflows #4

mpentler opened this issue May 27, 2018 · 4 comments
Labels
bug Something isn't working enhancement New feature or request help wanted Extra attention is needed

Comments

@mpentler
Copy link
Owner

Two things that kind of belong together. A quick code review by a friend picked up an immediately obvious potential buffer overflow in one file. Also I’ve had a few segfaults when switching between added hosts in the host list. No idea what caused them but I can get gdb on the case when I get time.

Realistically the entire codebase needs a through going over to make sure there’s nothing obviously dodgy in there.

@mpentler mpentler added bug Something isn't working enhancement New feature or request help wanted Extra attention is needed labels May 27, 2018
@mpentler
Copy link
Owner Author

Installed cppcheck and found some realloc errors. For example:

Checking src/net.cpp ...
[src/net.cpp:125]: (error) Common realloc mistake: 'answbuf' nulled but not freed upon failure
[src/net.cpp:130]: (error) Common realloc mistake: 'answbuf' nulled but not freed upon failure

Currently reading up on how to fix these with my limited C++ knowledge.

@mpentler
Copy link
Owner Author

Well, net.cpp now fixed. But others are proving a bit trickier.

@mpentler
Copy link
Owner Author

For the segfaults I’m getting they are constantly reproducible for me when switching between hosts:

Thread 5 "boinctui" received signal SIGSEGV, Segmentation fault.
�����������[Switching to Thread 0x74bff450 (LWP 32022)]
callbackStartElement (userdata=,
name=0x75e02208 "msg", atts=)
at src/resultparse.cpp:101
101 Item* parentitem = curitem.top(); //владелец всегда на верху стека

Seems it’s when parsing results from querying a host. But figuring it out is beyond me right now.

@mpentler
Copy link
Owner Author

mpentler commented Jun 3, 2018

This doesn’t seem right. Changing host during parsing of data from the remote host seems to screw the process up. Ideally the process would be cancelled and the next host would be contacted. Here’s some gdb output:

gdb-peda$ print curitem
$5 = std::stack wrapping: std::deque with -1 elements = {0x1a5b5e8, 0x769dd7c4 <main_arena+48>, 0x0,
0x0, 0x73fc9708, 0x75c026d0, 0x73fcc708,
0x73e19960, 0x73e15b78, 0x73e198b0, 0x73f074d8,
0x73f07458, 0x73e197a8, 0x73f07158, 0x73f06aa8,
0x73fd9220, 0x73fd89e0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, Cannot access memory at address 0x0

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant