| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8
Comments:
<0> Perhaps you should give up on C and go work with Stryst at McDonald's.
<1> heheheh
<2> gee snowman`_ thanx
<1> Caligo: wasn't for you.. I just like the calc
<1> Caligo: I was here the day that one got added
<2> is there a way to be certain if its the both forks?
<3> hmm... snowman==stryst?
<1> MarkT-: no
<2> since i dont want the parent to do the **** thats executed after the fork, what can i do in that case?
<2> ive got a if(fork()==0) { heres the **** done} i ***umed that "heres..." would only be done in the child? im i sadly mistaken?
<3> No, you're not mistaken.
<2> hmm...
<2> then i guess my problem isnt within the "parent<->child" area then?
<2> i would paste the code, but only the main file is like 400 lines big so
<1> where is your printf at
<3> calc paste
<0> Please paste your code (or a complete example that demonstrates your problem) here: http://rafb.net/paste/
<2> MarkT-: as i said, 400 lines.. seems like its better to try and "logic" search this problem
<3> is your printf inside the "****" for the if?
<2> MarkT-: yes
<3> paste it at rafb... let's take a look.
<4> printf buffering can do unexpected things across fork().
<3> caligo: it might just be a a typo that is causing the logic error.
<3> caligo: consider that one can theoretically solve a rubiks cube without looking at it, but that doesn't mean that's the best way to do it. let's take a look at the code.
<2> yeah, im doing some relevant pasting as we speak
<3> this really sounds like the printf is executing in both the parent and child though... at least from your description.
<3> By the way... have you tried putting in a printf("%d\n",getpid()) at the appropriate place as well?
<3> because if I'm right and both the parent and child are executing the print, then you'd see two different pid's
<3> but if the child is really executing it twice, the pid would be the same both times.
<4> You are forgetting that printf buffers.
<3> alex: shouldn't be an issue... this print is occuring after the fork.
<2> almost done
<4> Are there any prints prior to the fork?
<3> even if there were, it shouldn't print the stuff AFTER the fork twice...
<3> although it's possible that buffering issues could cause stuff that was printed before the fork to appear twice.
<3> (but I consider that possibility unlikely)
<4> Why does Caligo paste the code for us to look at?
<4> s/does/doesn't/
<3> He said he's doing that.
<3> I don't know why it's taking so long...
<4> Tell him to type faster.
<3> copy and paste normally takes about 10 seconds.
<3> (sigh)
<5> MarkT-: Those buffering issues have shown up in this channel a few times before.
<2> there we go
<2> http://www.rafb.net/paste/results/AXzsuV45.html
<2> now im done pasting
<3> Should I go with HDTV or not? I'm a little leery of it....
<2> added some comments to it aswell
<2> MarkT-: im trying out your getpid idea now
<4> MarkT-: I say NTSC forever!
<3> caligo: put it in the handlesocket() function
<3> OHHHH!
<3> You are calling handleClient TWICE.
<2> whoot :S
<3> caligo: You are calling it at line 50 and line 58
<3> The one at line 58 isn't inside an if at all.
<5> Caligo: Both the parent and child are calling handleClient().
<2> but theres an exit() in between? doesnt that take it out?
<5> Caligo: The one on line 58 is done by the parent, the one on 50 is done by the child.
<3> Caligo: Yes... the child will exit at that point
<5> But the parent keeps running.
<3> hund: actually the one at line 58 is done by both. The one on 50 is only done by the child.
<2> oh
<2> :S
<2> that suxx..
<3> If handleClient returned something other than 1 at line 50, then it would get called three times.
<2> :)
<5> MarkT-: No, handleClient always returns 1, and does an exit(0).
<3> Ah... okay, I hadn't gotten that far.
<2> so i.e the parent is calling something it really had no business doing
<5> That is, there's an exit() on line 51.
<5> Caligo: Why is line 58 there at all?
<2> im sure i had a reasonable explanation putting it there ....
<3> hund: Yes... I saw the exit, but it appeared that it was conditional (I don't know why)
<3> caligo: that's why it's doing it twice.
<5> Caligo: Maybe you planned on putting the fork() inside handleClient().
<2> hund: that might well be the case
<3> caligo: first... chop out line 58. Second, get rid of the condition at line 50... just call handleclient then call exit.
<3> The second thing is a readability issue, not an actual error.
<2> MarkT-: yeah, done it
<2> that took care of the dual stuff
<2> then the other problem
<2> why does buffer seem to hold junk even before i type in telnet?
<2> the "decoded" buffer i mean
<2> (the printf)
<3> caligo: because it's an automatic variable, and unitialized.
<3> and you are doing stuff with its contents before putting anything into it.
<3> oh my gawd....
<2> whot now?
<3> there are so many logical errors in handleclient it's not funny...
<3> you are using strlen to find info about the buffer?
<3> Is this supposed to be plain text coming through the buffer, by the way?
<2> in some cases :)
<2> well rather, the "decoded" buffer is always plaintext
<3> then why are you using strlen?
<2> uhm
<3> and even if it were plain text, strlen takes the length by finding a nul terminator, which probably won't get read on the socket.
<3> You can get the length of what you read by looking at the return result from the read() function
<2> hm
<2> notes that down
<3> But at line 83 you are also trying to use the contents of the buffer before you've initialized it... also likely to have unpredictavble consequences.
<3> You are also mallocing memory without freeing it, causing the function to slowly consume more and more memory
<2> ah, should free it when im done with it
<2> dun
<2> bare in mind this is like version 0.001 alpha or something
<2> :)
<3> Yes... although it's in a child process and would get freed when the child terminates, unless you are allocating something that's really supposed to be global for the whole process it's better form to free memory as soon as you can.
<2> true
<2> why use more memory even a split seccond than neccessary
<6> because batch (de-)allocation can be more efficient
<3> actually, you don't even really need to do a malloc there anyways.
<2> no?
<3> you could just do a printf on buff directly...
<2> look further down
<2> i need the pointer "decoded" to be handled by the handleCommands
<3> but you really need to read something into buff at line 83
<2> ill put a \0 as [0] in buff then?
<3> and don't use strlen unless you are SURE that it's zero terminated.
<3> No, caligo...
<3> (sigh)
<3> You put a \0 at the end of whatever it is that you read.
<2> yeah
<2> but in that "else" case, the buffer is empty
<2> and doing what i said did the trick :)
<2> got rid of the junk
<3> then why bother trying to use the buffer at all?
<2> because as i said, i need to send the pointer to handleCommands
<2> it needs a pointer even if the data is nothing
<2> (its handled in there)
<2> unless you know of a way to make a function (handleCommands) that can be ready to recieve either a pointer, or nothing
<3> caligo: if you initialize buff, then at line 83 buff will ALWAYS be empty... so there's no point in doing anything with it.
<2> its an if statement ffs
<2> if { data } else { no data }
<2> kinda
<2> since the app can move in 2 modes
<3> caligo: then change lines 83-85 to be: decoded=malloc(1); *decoded='\0';
<3> because there's nothing in buff at line 83 anyways.
<2> oh.. yea that is prettier
<3> and free(decode) before exiting
<3> er... free(decoded)
<2> yeah, that part ive done already
<2> :)
<3> wow...
<3> no offense caligo... but that code was SERIOUSLY ****ed up.... I would've had a field day with my red marker if code like that were on a paper I was grading...
<3> er.. ***ignment, not paper...
<2> MarkT-: yeah i know there are lots of code in there that either need some optimizing, removal, or just plain redoing
Return to
#c
or
Go to some related
logs:
#delphi
#windows
#eggtcl
#debian
CAL Liscensing
#goal
#microsoft
#mirc
quotetracker layout
#linuxhelp
|
|