Segmentation fault...

2

Comments

  • : In fact, there were no errors in these functions (except in match() but it is not called). Sorry, I wrote this without reading your code again :-(. However, there were a few useless statements:
    :
    : [b]In Lookup()[/b]
    : There is no need to compare just the first character of list[n] and s and if they are the same then compare the whole strings. Why don't you only compare the entire strings?
    :
    [blue]
    It a lot faster. Even if strcmp is rather fast, it's still slow in compared to just comparing two bytes.
    [/blue]

    : [b]In getNum()[/b]
    : It is useless to call upcase() in the while loop since look is a digit here.
    :
    : [b]In getOp()[/b]
    : Same thing than in getNum().
    :
    [blue]
    Thanks for that, I didn't think of it...
    I'll change it right away.
    [/blue]

  • : : :
    : : : : What is wrong in the way you use pointers is the fact that you do not always allocate memory before writing to the location pointed to by the pointer. For example, you need to allocate memory before calling scanf().
    : : : : By the way, I tested the corrected code and it appears to work.
    : : : :
    : : : : Steph
    : : : :
    : : : What was wrong using scan()?
    : : :
    : : : It worked with scanf(). If I should have allocated memmory for c and didn't it should give a segmentation fault, but it did not.
    : : :
    : : :
    : : Your call to scan() was OK since scan() calls functions which allocate memory (except the fact that there were other errors in these functions; they are corrected in the version I posted). What concerns scanf(), I am sure you need to allocate memory before calling scanf(). Check out the doc of this function. Such programming errors often lead to segmentation faults but not always. If you are "lucky", it will just overwrite other variables in your program. Segmentation faults occur when your program attempts to write to a block of memory which does not belong to your program.
    : :
    : : Steph
    : :
    : To help this I think I always should init all pointers to null.
    : Your code was good, thanks.
    : I didn't like the intends and the funcs shouldn't return a pointer to char so I rewrote them:
    : [code]
    : void getOp(char *c){
    : char *p;
    : p = c;
    : if(!IsOp(look)) Expected("Integer");
    : while(IsOp(look)){
    : *p = upcase(look);
    : ++p;
    : GetChar();
    : }
    : *p = 0;
    : skipWhite();
    : }
    : //and similar with the others, getNum and getName
    :
    : void scan(char* c){
    : skipWhite();
    : while(look == '
    ')
    : Fin();
    :
    : if(IsAlpha(look))
    : getName(c);
    : else if(IsDigit(look))
    : getNum(c);
    : else if(IsOp(look))
    : getOp(c);
    : else {
    : *c = look;
    : ++c;
    : *c = 0;
    : --c;
    : GetChar();
    : }
    : }
    :
    :
    : [/code]
    :
    : I'm still not sure what the problem was...
    :
    :
    : : (except the fact that there were other errors in these functions; they are corrected in the version I posted)
    :
    : What errors?
    :
    Well, I am not sure but I think I found something.
    One of the causes may be the fact that a name should not be longer than 8 chars since getName() only allocates 9 bytes. Same thing with getNum() where numbers in the input stream should not be longer than 16 chars. Finally in getOp() an operator should not be longer than 3 chars. However, I think you have thought about that and allocated enough memory in each case.
    Anyway, there is a problem in init(). Sorry, I had not noticed that before. You allocate only 6 bytes for KWlist whereas you should allocate 5*sizeof (char *) which often equals 5*4=20 bytes for 32-bit pointers or 5*2=10 bytes for 16-bit pointers. What I do not understand is the fact that the segmentation fault did not occur every time the program was running; this allocation error should have caused a runtime error in init() when you initialize the KWlist array. It leads to another problem in Lookup() when you compare s with the different elements of KWlist which is not in fact as long as you suppose since you did not allocate enough memory.
    Something that is also strange to me is the fact that it worked when Lookup() received 3 or less as its second parameter. It could be explained this way. If your compiler is set to generate code for 16-bit pointers (possible with the old Turbo C), then you allocate in fact an array of 6/2=3 pointers to char instead of 5. So if Lookup() receives more than 3, when you compare the strings, you attempt to read memory which has not been allocated, and this may lead to segmentation faults. However, this explanation supposes that no error occurred in init(), which I think very strange.
    I do not have any other explanation so far. Did you test your program many times? I mean 10 times or more when passing 3 or less to Lookup().
    Well, segmentation faults do not always occur and a program may generate a fault at one time and run without any problem at another time. However, this problem appears really strange to me and I am sorry to say that I do not have any other explanation, since I did not find any other error :-(. Perhaps somebody else on the messageboard could explain that phenomenon; I personnaly cannot.

    Steph
  • : : In fact, there were no errors in these functions (except in match() but it is not called). Sorry, I wrote this without reading your code again :-(. However, there were a few useless statements:
    : :
    : : [b]In Lookup()[/b]
    : : There is no need to compare just the first character of list[n] and s and if they are the same then compare the whole strings. Why don't you only compare the entire strings?
    : :
    : [blue]
    : It a lot faster. Even if strcmp is rather fast, it's still slow in compared to just comparing two bytes.
    : [/blue]
    :
    : : [b]In getNum()[/b]
    : : It is useless to call upcase() in the while loop since look is a digit here.
    : :
    : : [b]In getOp()[/b]
    : : Same thing than in getNum().
    : :
    : [blue]
    : Thanks for that, I didn't think of it...
    : I'll change it right away.
    : [/blue]
    :
    :
    I am not sure that what you mentionned about the speed of a program comparing strings is true. How would you implement strcmp()? This way for example:
    [code]
    int strcmp(char *s1,char *s2)
    {
    while (*s1 && *s1==*s2)
    {
    ++s1;
    ++s2;
    }
    if (*s1<*s2) return -1;
    else if (*s1>*s2) return 1;
    else return 0;
    }
    [/code]

    As you can see, not the whole strings are compared. The algorithm stops as soon as a difference is detected. That's why I do not think it would cost more time to call strcmp() directly (except the cost of a call to a function :-)).

    Steph
  • Just wanted to point out that you are still following
    the strcmp spec if do like this:

    [code]
    int strcmp(const char *s1, const char *s2)
    {
    while (*s1 && *s1==*s2)
    {
    ++s1;
    ++s2;
    }
    return *s1 - *s2;
    }
    [/code]


    Ok, hum... so I optimized it with one CPU tick or so...? :-)
    What's important to know is that the version of this function provided by the compiler is probably heavily optimized and most likely inlined as well.
  • : Well, I am not sure but I think I found something.
    : One of the causes may be the fact that a name should not be longer than 8 chars since getName() only allocates 9 bytes. Same thing with getNum() where numbers in the input stream should not be longer than 16 chars. Finally in getOp() an operator should not be longer than 3 chars. However, I think you have thought about that and allocated enough memory in each case.
    : Anyway, there is a problem in init(). Sorry, I had not noticed that before. You allocate only 6 bytes for KWlist whereas you should allocate 5*sizeof (char *) which often equals 5*4=20 bytes for 32-bit pointers or 5*2=10 bytes for 16-bit pointers. What I do not understand is the fact that the segmentation fault did not occur every time the program was running; this allocation error should have caused a runtime error in init() when you initialize the KWlist array. It leads to another problem in Lookup() when you compare s with the different elements of KWlist which is not in fact as long as you suppose since you did not allocate enough memory.
    : Something that is also strange to me is the fact that it worked when Lookup() received 3 or less as its second parameter. It could be explained this way. If your compiler is set to generate code for 16-bit pointers (possible with the old Turbo C), then you allocate in fact an array of 6/2=3 pointers to char instead of 5. So if Lookup() receives more than 3, when you compare the strings, you attempt to read memory which has not been allocated, and this may lead to segmentation faults. However, this explanation supposes that no error occurred in init(), which I think very strange.
    : I do not have any other explanation so far. Did you test your program many times? I mean 10 times or more when passing 3 or less to Lookup().
    : Well, segmentation faults do not always occur and a program may generate a fault at one time and run without any problem at another time. However, this problem appears really strange to me and I am sorry to say that I do not have any other explanation, since I did not find any other error :-(. Perhaps somebody else on the messageboard could explain that phenomenon; I personnaly cannot.
    :
    : Steph
    :
    It sounds good. I allocated 6 bytes, wich is enough for 3 pointers, and no more. Maybe the compiler or OS optimised away the assignment in init, or something. Thanks.
  • : : Well, I am not sure but I think I found something.
    : : One of the causes may be the fact that a name should not be longer than 8 chars since getName() only allocates 9 bytes. Same thing with getNum() where numbers in the input stream should not be longer than 16 chars. Finally in getOp() an operator should not be longer than 3 chars. However, I think you have thought about that and allocated enough memory in each case.
    : : Anyway, there is a problem in init(). Sorry, I had not noticed that before. You allocate only 6 bytes for KWlist whereas you should allocate 5*sizeof (char *) which often equals 5*4=20 bytes for 32-bit pointers or 5*2=10 bytes for 16-bit pointers. What I do not understand is the fact that the segmentation fault did not occur every time the program was running; this allocation error should have caused a runtime error in init() when you initialize the KWlist array. It leads to another problem in Lookup() when you compare s with the different elements of KWlist which is not in fact as long as you suppose since you did not allocate enough memory.
    : : Something that is also strange to me is the fact that it worked when Lookup() received 3 or less as its second parameter. It could be explained this way. If your compiler is set to generate code for 16-bit pointers (possible with the old Turbo C), then you allocate in fact an array of 6/2=3 pointers to char instead of 5. So if Lookup() receives more than 3, when you compare the strings, you attempt to read memory which has not been allocated, and this may lead to segmentation faults. However, this explanation supposes that no error occurred in init(), which I think very strange.
    : : I do not have any other explanation so far. Did you test your program many times? I mean 10 times or more when passing 3 or less to Lookup().
    : : Well, segmentation faults do not always occur and a program may generate a fault at one time and run without any problem at another time. However, this problem appears really strange to me and I am sorry to say that I do not have any other explanation, since I did not find any other error :-(. Perhaps somebody else on the messageboard could explain that phenomenon; I personnaly cannot.
    : :
    : : Steph
    : :
    : It sounds good. I allocated 6 bytes, wich is enough for 3 pointers, and no more. Maybe the compiler or OS optimised away the assignment in init, or something. Thanks.
    :
    May you tell me what compiler you use so that I know whether it is most likely to use 32- or 16-bit pointers?

    Steph
  • Maximum thread limit...

    That's how strcmp worked. I had no idea.

    My way is compiled to just one instruction CMPS, wich is just 5 cycles on a Pentium.
    The strcmp func could, as I can see it, only be optimised to a loop, (since there is two comparisons to be made).

    I don't know how to say this but something like this:
    The case for it to match is small, one in 26 or similar.
    Since strcmp is slower than my way, and the probability for a match is low, the extra comparison for a match will not differ much.

    My way: 25 times cmps and one strcmp
    only strcmp: 26 times strcmp
  • Max thread limit again...

    I use gcc
  • : Maximum thread limit...
    :
    : That's how strcmp worked. I had no idea.
    :
    : My way is compiled to just one instruction CMPS, wich is just 5 cycles on a Pentium.
    : The strcmp func could, as I can see it, only be optimised to a loop, (since there is two comparisons to be made).
    :
    : I don't know how to say this but something like this:
    : The case for it to match is small, one in 26 or similar.
    : Since strcmp is slower than my way, and the probability for a match is low, the extra comparison for a match will not differ much.
    :
    : My way: 25 times cmps and one strcmp
    : only strcmp: 26 times strcmp
    :


    Well, you are using a PC... If you get a context switch in the middle of the whole thing you are probably gone for thousands of strcmp. Might be worth it to make the code more readable and sacrifice some performance.

  • : Maximum thread limit...
    :
    : That's how strcmp worked. I had no idea.
    :
    : My way is compiled to just one instruction CMPS, wich is just 5 cycles on a Pentium.
    : The strcmp func could, as I can see it, only be optimised to a loop, (since there is two comparisons to be made).
    :
    : I don't know how to say this but something like this:
    : The case for it to match is small, one in 26 or similar.
    : Since strcmp is slower than my way, and the probability for a match is low, the extra comparison for a match will not differ much.
    :
    : My way: 25 times cmps and one strcmp
    : only strcmp: 26 times strcmp

    I agree with the fact that a call to strcmp() plus the extra comparison require a little more time to execute than your single comparison. However, unless you compare thousands of strings, do you think you'll notice the difference between the two methods?

    Steph

  • : Max thread limit again...
    :
    : I use gcc
    :
    What do you mean when you write "Max thread limit"? I do not understand.

    Steph
  • : : Max thread limit again...
    : :
    : : I use gcc
    : :
    : What do you mean when you write "Max thread limit"? I do not understand.
    :
    : Steph
    :

    The damned message board only allows 10 messages/threads in a row.
    So it has nothing to do with kernel objects :-)
  • : : : Max thread limit again...
    : : :
    : : : I use gcc
    : : :
    : : What do you mean when you write "Max thread limit"? I do not understand.
    : :
    : : Steph
    : :
    :
    : The damned message board only allows 10 messages/threads in a row.
    : So it has nothing to do with kernel objects :-)
    :
    OK! Thanks. I must really be tired to have not understood this :-).
    Steph
  • : : Maximum thread limit...
    : :
    : : That's how strcmp worked. I had no idea.
    : :
    : : My way is compiled to just one instruction CMPS, wich is just 5 cycles on a Pentium.
    : : The strcmp func could, as I can see it, only be optimised to a loop, (since there is two comparisons to be made).
    : :
    : : I don't know how to say this but something like this:
    : : The case for it to match is small, one in 26 or similar.
    : : Since strcmp is slower than my way, and the probability for a match is low, the extra comparison for a match will not differ much.
    : :
    : : My way: 25 times cmps and one strcmp
    : : only strcmp: 26 times strcmp
    : :
    :
    :
    : Well, you are using a PC...

    Who doesn't?

    : If you get a context switch in the middle of the whole thing you are probably gone for thousands of strcmp.

    ?? Maybe my english is bad but I can't figure out what it says.

    : Might be worth it to make the code more readable and sacrifice some performance.
    :

    I don't agree that it makes it more readable to remove them.
  • : : Maximum thread limit...
    : :
    : : That's how strcmp worked. I had no idea.
    : :
    : : My way is compiled to just one instruction CMPS, wich is just 5 cycles on a Pentium.
    : : The strcmp func could, as I can see it, only be optimised to a loop, (since there is two comparisons to be made).
    : :
    : : I don't know how to say this but something like this:
    : : The case for it to match is small, one in 26 or similar.
    : : Since strcmp is slower than my way, and the probability for a match is low, the extra comparison for a match will not differ much.
    : :
    : : My way: 25 times cmps and one strcmp
    : : only strcmp: 26 times strcmp
    :
    : I agree with the fact that a call to strcmp() plus the extra comparison require a little more time to execute than your single comparison. However, unless you compare thousands of strings, do you think you'll notice the difference between the two methods?
    :
    : Steph
    :
    That's what I'm planning to do, compare thousands of strings.
    I'm making a compiler.
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories