Ask coding questions

← Back to all posts
Vector splitting and reassigning causes seg fault when using 8-byte vectors
xxpertHacker

I add everything in an array of 256 bytes by adding the second half into the first half.

The algorithm is the following pseudo-code:

Now, I implemented this using some very unsafe C++ with GNU vector extensions, and it segfaults once it uses the 8-byte vector:

Yet I can't tell why it sucessfully executes the first 4 statements.

In my implementation, I perform each line of the above via a call to sum_half. The function reinterprets the longest vector as two smaller vectors based on the starting byte offset of the vector, and with the second vector based off of the byte offset of the first, offset further by the length of the new vector.

Can anyone review the code and determine what causes the segfault?

Voters
programmeruser
DynamicSquid
xxpertHacker
Comments
hotnewtop
xxpertHacker

@realTronsi Made sure not to use my brain, wanna check it out?

realTronsi

@xxpertHacker I'm confused, what do arrays have to do with vectors. Could you word your question a bit better and also perhaps make your code more friendly

xxpertHacker

@realTronsi Updated the post. How much friendlier can the code be?

realTronsi

@xxpertHacker Idk if repl is being DoSed rn but I can't load into any repls so I'll look into it once I can actually open up rels

xxpertHacker

@realTronsi I was barely able to open it, and edited it a bit.

All week it's been slow, Repls have been crashing often.

realTronsi

@xxpertHacker the main.cpp file won't even load so I can't see the code anymore, and it won't let me fork either. Oh well.

realTronsi

@xxpertHacker just one thing, what are the results of vector casts to integers and vice versa?

The culprit has something to do with the bit shifting I believe.

xxpertHacker

@realTronsi

...vector casts to integers and vice versa?

This is never done?

I only use vector<->pointer casts.

For example, given the vector vec<4> v = [ 1, 1, 1, 1 ], I take the address of the zeroth element (&v[0]), and the middle of the vector (&v[2]), and reinterpret both as vec<2>*, then load them as &vec<2> and perform the addition.

Because the idea doesn't map as well to code, I get the byte offset of the vector, for example:

add half of the vector's length:

and load the second half as a vector, which in the example above would be [ 3, 4 ].

I carefully made sure to not accidentally reinterpret any plain numbers as pointers (I accidentally reinterpreted a u8 as a vector pointer once).

Does the above explanation help grasp the situation?

xxpertHacker

@realTronsi Unrelated, but it wasn't there before, and it's terrifying... check the last elements of the vector printing...

realTronsi

@xxpertHacker

Unrelated, but it wasn't there before, and it's terrifying

Ha, if you ever code in assembly or smth all the bugs just kinda sit there until 2 hours later when you've added 100 more lines of code and they all just emerge and you have no idea wtf is going on because everything was working before... yeah.


Also I understand your code and there doesn't seem to be anything immediately wrong with it, though admittedly I don't use C++ so I'm not aware of any of it's potential quirks.

Anyways one pattern I did notice is that this seg fault is only present with a SHIFT of 4. Doesn't seem like that special of a number tho unless C++ uint8_t's or vectors have some grudge with 4.

xxpertHacker

@realTronsi

...this seg fault is only present with a SHIFT of 4...

Wait, did you skip ahead and try 5..7?

realTronsi
xxpertHacker

@realTronsi Early in the code, I had severe alignment issues, so the entire second half of the vector would be overwritten with garbage upon every call. Technicially it was okay since after every call the second half is unused, wasted memory, but it was a bug nonetheless.

After correctly aligning the vector (I was initially using an array), and fixing my types, it seemed to work fine, but now there's a bit of garbage at the end, and I'm not sure why that is.

realTronsi

@xxpertHacker did you see my forked version? Only a SHIFT of 4 invokes the bug for some reason.

xxpertHacker

@realTronsi No, Replit won't load your fork for me.

I'll try later.

realTronsi

@xxpertHacker you know anything about 3d segment to face collision detection?

xxpertHacker

@realTronsi Nope, sorry.

xxpertHacker

@realTronsi I think x86 only has packed integer instructions for operating on 128 bits at a time, so I think that would be 16 sets of 8 bits at a time, which maps exactly to the shift of 4, since 0x100 >> 4 = 16. Not sure if it's relevant though.

I'm not seeing any xmm registers or operations being emit for -O0.

Updated to emit asm & machine code when pressing run, could you check it out?

realTronsi

@xxpertHacker repl won't load for me anymore, I'll check it out tomorrow. (Also cmon get discord back again or smth, using repl to communicate is terrible)

xxpertHacker

@realTronsi So, let's say that we had an alternative means of communication, how would that help? You couldn't see the code anyways.

realTronsi

@xxpertHacker there are many websites just like repl which you could use to share the code... besides you can send code through discord, and we also don't have to talk with each other like we're writing letters to each other in the 19th century

xxpertHacker

@realTronsi But I can't always access the Repl to get the code in the first place.

Als, maybe try getting the zip before opening the Repl?

realTronsi

@xxpertHacker the entire thing just won't load. Also but still see how we're responding hours apart? It's just not practical

xxpertHacker

@realTronsi Well, I'm responding to other people on Discord already, and quite occupied

realTronsi

@xxpertHacker I thought you deleted your discord...

realTronsi

@xxpertHacker I can't understand this machine code, obviously. Like how am I supposed to read this

anyways just take your question to SO then. If you get a response there let me know because I'm curious as well

xxpertHacker

@realTronsi Okay, the name mangling is pretty bad, and maybe I will later.