Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Rose]

Is there any reason you don't want to have it user selectable?

[miauw62]

With branches, when you push to them, won't they go back to the master? Eg, if joystick was master and then I made some changes to it then pushed to controller, wouldn't it replace the controller code with joystick code?

I think you'd have the same problem with forks. You can cherrypick commits from one branch to another if they're in the same repo, so having seperate branches seems MORE convenient.

[MorleyDev]

Why are you trying to fix that at the version control level? My first instinct would be to use factories, conditional compilation, or some combination of the two. What's stopping that approach? I mean, as lightweight as git branches are, you still have practically two copies of the entire codebase you have to manage at that point. Seems like a maintenance nightmare waiting to happen.

[Bauglir]

So, I'm learning the joys of segfaults in C. I've figured out exactly where the problem is being caused, but I cannot for the life of me figure it out.

I have an int variable, acked. I declare it and initialize it to -1 before entering a loop:

Code: [Select]

int acked = -1;
Near the end of the loop, I assign to it a cast unsigned char pulled out of an array:

Code: [Select]

acked = (int) srv_reply[1];
All goes well, until srv_reply[1] turns out to be 6. When this happens, accessing acked causes a segfault on the FOLLOWING iteration of the loop. I can print it, for instance, just fine BEFORE the loop ends the iteration in which acked is assigned to 6, but move that instruction up to the top of the loop and all hell breaks loose.

Unfortunately, due to the way I've jiggered the logic here, I don't have the option of moving what I need to do with it to the bottom without having to rewrite a bunch of this. I'll do so if it comes to it, but aside from being frustrating, not knowing what the hell is going on is to bug me forever.

[RulerOfNothing]

How are you accessing acked?

[alexandertnt]

Also how are you printing? If your not printing to stderr, than it might not actually display some of the messages in the terminal before the segfault.

[Bauglir]

Well, currently, I'm just calling printf("%d", acked);

In the original code, I was doing

Code: [Select]

int toClean;
for(toClean = 0; toClean < acked; toClean++){
    inTransit[toClean] = 0;
}

But that's currently commented out. Notably, commenting out the contents of the loop doesn't prevent a segfault (so my initial guess that it had something to do with inTransit, which at least involves pointers, was wrong).

I am a tremendous noob to C, though, so I'm going to go look up how to print to stderr after making this post.

Also, for a little more clarity:

No problems:

Code: [Select]

int acked = -1;
while(1){
    <Stuff>
    acked = (int) srv_reply[1];
    printf("%d", acked);
}
Segfault:

Code: [Select]

int acked = -1;
while(1){
    printf("%d", acked);
    <Stuff>
    acked = (int) srv_reply[1];
}
EDIT: Interestingly, printing to stderr did get one more print off before segfaulting, and I've noticed something that, quite frankly, is fucking bizarre - the segfault only occurs if I try to access acked, but it appears to occur AFTER I do so - another loop nested within that <Stuff> region includes its own print statements, and it gets two out of the three done before Segmentation Fault prints and the whole thing quits.

So, uh, fuck this noise, I'll rewrite the thing to be a little more straightforward, a little less efficient, a lot less elegant, and specifically to avoid needing to use this variable.

[EnigmaticHat]

Frankly, I don't know how C works but I do know that there is no error that cannot be found by commenting out different parts of the code until the error stops.  Or if your changes were recent, undoing changes until the error stops.  Note: I am not responsible for reckless hyperbole contained within this post.

[alexandertnt]

Can I see <Stuff>? In particular, I am intersted in the declaration of srv_reply.

[Orange Wizard]

Code: [Select]

try:
    do_stuff()
except:
    pass


[Putnam]

I present to you all before I go to bed the horrifying if statement I had to write today:

Code: [Select]

elseif event[3]==(string.len(derweight)~= 23 and string.len(derweight)+3 or string.len(derweight)+4) then
This was so I had a button to press in a Minecraft computercraft monitor. Apparently, there was no X coordinate 26, which coincidentally happened to be the one I needed; to this end, I made it so that, if the length of the weight of the string showing the derivative in the PID system is exactly 23 characters in length, the button will be placed one column to the right.

I feel dirty.

[Bauglir]

Can I see <Stuff>? In particular, I am intersted in the declaration of srv_reply.

Sure. Basically I'm simulating a transmission of the alphabet in two-letter blocks from one computer to another.

Code: [Select]

void primary(int sockfd, double ber) {
    int read_size;
    unsigned char msg[6];
//Packet Structure:
//[0] = packet type (data = 0xAA, ack = 0xF0, nak = 0x0F)
//[1] = sequence number (element of [0, 12])
//[2] = high data byte, first character
//[3] = low data byte, second character
//[4] = high byte of CRC check
//[5] = low byte of CRC check
    unsigned char srv_reply[6] = {0x0F, 0, 0, 0, 0, 0};
        //Initialize srv_reply to dummy NAK to initiate transmission.
    unsigned char sendWindow[3] = {0, 1, 2};
    char inTransit[13] = {0};
        //The value at the index of a given packet's sequence number will be set to 0xFF when that packet is in transit, and reset to 0 when not.
    int acked = -1;//The sequence number of the last ACK packet
   
    //Constantly communicate with server.
    while(1){
        //Assume that replies from receiver are error free; error-checking not implemented.

fprintf(stderr, "Numbers: %d \n", acked);//SEGFAULT HAPPENS IF THIS LINE IS PRESENT.

if(srv_reply[1] == 13){//ACK/NAK received for packet 13, that is one packet more than the actual message; either way, packet 12 acknowledged. Should just make this part of While condition.
            break;
}

if(srv_reply[0] == 0x0F){//Code for a NAK.
    //Retransmit the entire window.
    int toRetrans;
    for(toRetrans = 0; toRetrans < 3; toRetrans++){//SEGFAULT HAPPENS ON toRetrans == 3, IF SEGFAULT-CAUSING LINE PRESENT ABOVE
if(sendWindow[toRetrans] > 12){//Don't transmit packets we don't have data for. Magic number is bad, fix later.
    break;
      }

                //Add condition to prevent printing on initial dummy NAK.
printf("Packet %d retransmitted due to NAK %d.\n\n", sendWindow[toRetrans], srv_reply[1]);

makePack(msg, 0xAA, sendWindow[toRetrans], ALPHABET[sendWindow[toRetrans]*2], ALPHABET[sendWindow[toRetrans]*2+1]);
sendPacket(msg, ber, sockfd);
inTransit[msg[1]] = 0xFF;
                //Make a packet, stored in msg, with type Data, sequence number from the send window, and the appropriate alphabet characters.
        //Each packet has 2 characters, so multiply the *packet* number by 2 for the first, then add 1 to that for the next.
                //Then send the packet, and update the inTransit list so that we don't redundantly send this packet out again later.
    }
}
else if(srv_reply[0] == 0xF0){//Code for ACK.

    printf("Packet %d requested by receiver.\n", srv_reply[1]);

    //int toClear;//THIS FOLLOWING LOOP IS THE SEGFAULT-CAUSING CODE I ACTUALLY NEEDED TO DO
    //for(toClear = 0; toClear < acked; toClear++){
//inTransit[toClear] = 0;
    //}

    if((sendWindow[0] <= srv_reply[1] && sendWindow[2]+1 >= srv_reply[1]) && !inTransit[srv_reply[1]]){//If the requested packet is within the send window, and not already in transit

makePack(msg, 0xAA, srv_reply[1], ALPHABET[srv_reply[1]*2], ALPHABET[srv_reply[1]*2+1]);
sendPacket(msg, ber, sockfd);
inTransit[srv_reply[1]] = 0xFF;
                //Same packet-sending procedure as for NAK, but send only one packet, and grab your data directly from the packet you got.
    }
//If requested packet is outside send window, do nothing.
}

else{
    printf("VERY strange things are afoot - I don't know what's wrong, but you got an impossible packet.");
}

        //Check to see what's received LAST because we need to go through the whole process with the dummy NAK at first.
if( (read_size = recv(sockfd, srv_reply, 6, 0)) < 0){
    perror("recv failed");
    break;
}

acked = (int)srv_reply[1];//ASSIGN VALUE TO ACKED
windAdjust(sendWindow, srv_reply[1]);//Slide the send window appropriately
    }
}

sockfd is a socket number for the transmission, and ber is an error rate for the transmitted packets (no errors occur in the receiver's reply, though).

Functions you see in there:
makePack just assigns the correct data to the slots of a given array to make a packet according to the format we've been given, including running a CRC check and all that stuff.
sendPacket handles the actual sending, and involves a function we've been given only as an object file (that is, no source code). I could post the code for sendPacket, but it's basically just printing and busywork, plus the mystery function that actually does the sending.
windAdjust slides the sending window (an array of packets that we're allowed to send before getting acknowledgement of an already-sent packet, basically).

recv, the interesting one to you guys most likely, is the receiving counterpart to the sending function we were provided as an object file. That is, I have no source for it. What I know it does is return a number indicating the size of a packet (and a negative number in case of weird things happening), and as a side effect it fills a given array with the contents of a packet of known length (here, 6). The 0 apparently turns off special options that we don't need for this. Notably, printing acked immediately after assigning it, or after sliding the send window, works just fine - it's not until it gets to the next iteration of the loop that things break.

It has just occurred to me that acked isn't really doing anything and I could probably just cut it out; I'm already just looking directly at the packet number anyway in most places, so I'm not sure why I thought this was necessary anymore. I should also move the toClear loop outside the code for either NAKs or ACKs specifically, since it ought to run in both cases anyway. Still, doesn't solve the mystery, just the problem.

[Bauglir]

On the one hand, I hate to double post, but on the other, I think I should inform you guys of two new developments and it probably merits a new post. On the one hand, the segfaults mysteriously vanished after I replaced the actual code with what I posted here because I like the comments better (I changed none of the actual code). On the other, now code that I've commented out is being executed. So. At this point, I'm convinced that the problem is not with the code, but with the machine, which is clearly bonkers - never programming on a virtual machine again, that's for sure (if that turns out to have been relevant, I apologize for not mentioning it; I was having a hell of a time figuring out how to use the provided .o files on Windows, so I switched over to a virtual Linux machine on which I could use a more familiar compiler and suchlike, at least).

[alway]

You mention virtual machine and copy-paste along with odd behavior relating to line endings. Windows and linux line endings tend to be slightly different; it's one of the little pains that come with switching between the two. Could be you're being hit by that.

[Gentlefish]

Doesn't one use carriage return and the other the newline? I definitely remember hearing about that, and I've experienced it first-hand lp'ing from a linux.