Weird errors

This is a discussion on Weird errors within the C++ Programming forums, part of the General Programming Boards category; If it's not returning -1, it's not actually entering the catch blocks. The fact it continues on with the function ...

  1. #16
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    If it's not returning -1, it's not actually entering the catch blocks. The fact it continues on with the function after that is proof. It's going past the try...catch successfully, meaning no exception was thrown.

    Also, unless your compiler has a switch to catch access violations as C++ exceptions, there's nothing which can generate an exception, it's all memory copying which is guaranteed not to throw a (C++) exception. Even if you can tell your compiler to catch an access violation, you'd need to catch with a catch(...), so the catch statements you have are useless, they'll never actually catch anything. Those catch statements are effectively unreachable code, in fact your compiler may have completely removed them.


    Whatever your bug is, it's not in the code you pasted.

    And yes, the bug is in your code somewhere, but it's not in the code you listed.
    Last edited by Cat; 10-15-2006 at 04:18 AM.
    You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.

  2. #17
    Registered User
    Join Date
    Mar 2006
    Posts
    725
    thats the thing, i could use standard defined ones but that would be much slower, this is a strlen and strcpy in one and the whole application is based on speed.
    Again, premature optimization is the root of all evil (Hoare, Knuth). (Think I'll need to dump this in my sig sometime.) For all you know, the strlen() and strcpy() provided by your compiler libs might be implemented in pure optimized assembly, tuned to the last clock cycle by tens of developers with years of experience in assemblers and compiler design. For all you know they are written as seperate micro-functions to fit completely into your platform's pipeline cleanly so as not to require additional instruction fetches by the processor. For all you know...

    First profile (to the millisecond) strcpy and strlen running 1,000,000 times each in adverse conditions, also profiling the kernel, cache, swap and other side-effect processes. Then repeat for various optimization levels of your compiler and for various target platforms. Then profile your entire application to see if the bottlenecks are in these functions. Then, and only then, do you go to the trouble of coding your own buggy, less-portable replacements.


    you might think that with buffer+=3, i have a overflow but thats not. bufptr points to the very beginning of a large large array of chars named buffer.
    How large? This large? This large? This large? Can you be sure that the buffer is large enough? What if a user (including other processes and automated clients) enter a very large string for one of the fields? Why not just use std::string, which is all fast, easy and safe? I think there are some fundemental doo-wizzahs about your overall code design.
    Code:
    #include <stdio.h>
    
    void J(char*a){int f,i=0,c='1';for(;a[i]!='0';++i)if(i==81){
    puts(a);return;}for(;c<='9';++c){for(f=0;f<9;++f)if(a[i-i%27+i%9
    /3*3+f/3*9+f%3]==c||a[i%9+f*9]==c||a[i-i%9+f]==c)goto e;a[i]=c;J(a);a[i]
    ='0';e:;}}int main(int c,char**v){int t=0;if(c>1){for(;v[1][
    t];++t);if(t==81){J(v[1]);return 0;}}puts("sudoku [0-9]{81}");return 1;}

  3. #18
    Registered User
    Join Date
    May 2006
    Posts
    30
    yes your right, got confused with the ESI

  4. #19
    Registered User
    Join Date
    May 2006
    Posts
    30
    Quote Originally Posted by jafet
    Again, premature optimization is the root of all evil (Hoare, Knuth). (Think I'll need to dump this in my sig sometime.) For all you know, the strlen() and strcpy() provided by your compiler libs might be implemented in pure optimized assembly, tuned to the last clock cycle by tens of developers with years of experience in assemblers and compiler design. For all you know they are written as seperate micro-functions to fit completely into your platform's pipeline cleanly so as not to require additional instruction fetches by the processor. For all you know...

    First profile (to the millisecond) strcpy and strlen running 1,000,000 times each in adverse conditions, also profiling the kernel, cache, swap and other side-effect processes. Then repeat for various optimization levels of your compiler and for various target platforms. Then profile your entire application to see if the bottlenecks are in these functions. Then, and only then, do you go to the trouble of coding your own buggy, less-portable replacements.




    How large? This large? This large? This large? Can you be sure that the buffer is large enough? What if a user (including other processes and automated clients) enter a very large string for one of the fields? Why not just use std::string, which is all fast, easy and safe? I think there are some fundemental doo-wizzahs about your overall code design.
    hence jafet, i've got to learn to. coming bit by bit but still. anyway, the input is the content of a UDP packet wich is widely secured. maybe 20 procent of the buffer will be constantly filled. and indeed, maybe i did overdue myself a bit writing that strcpy function but hey it works fine and it doesnt produce any errors. for the rest , im a big fan of c++, i tried to make the most parts in my application c++ based. vectors or deques instead of arrays, no functors but inheriting and so on. still it will take time and experiance before im at a level where both i and others can say im good. anyway back to ontopic. its a interresting post there cat. i've red some articles about exception handling, ( codeproject.com - "How c++ implements exeption handling" is a very nice one) and i do understand things now. still i dont understand why the jump is there but still it might be some debugger stuff or who knows. if i find out more ill post it here. till that time on, any suggestions would be welcome

    one other question, with strings where you dont reserve a specific ammount before, will the memory get fragmented?

  5. #20
    Registered User
    Join Date
    Jan 2005
    Posts
    7,319
    >> with strings where you dont reserve a specific ammount before, will the memory get fragmented?
    Probably not with most string representations. However, if you don't reserve space beforehand, you might cause re-allocations if you continually append to it. This should only be a problem if you are appending a bunch of times (dozens, hundreds, thousands, etc).

  6. #21
    Registered User
    Join Date
    Oct 2006
    Posts
    250
    Quote Originally Posted by DV64h
    yes your right, got confused with the ESI
    You really should (1) work on your spelling, and (2) read up on the basics of x86 registers (http://www.eecg.toronto.edu/~amza/ww...s/x86regs.html).

  7. #22
    Registered User
    Join Date
    May 2006
    Posts
    30
    pff sorry to say this for the admins but, i seem to find a lot of flaming, i can understand that you can get really irritating because of some beginners ( got some experiance myself like someone telling me: "using the std library is for noobs") , but still... you know what i mean. i dont have a school telling me how to program, i dont have a school telling how english works and i know there are a lot more like me just willing to learn but dont have the best resources. I've been helped here, yes, i've got some nices answers to some of my questions but still when i got to read: "You really should (1) work on your spelling", i think hey,what do you expect im doing? anyway, thanks for the link however i've already ordered a book on assembly. hoping it will teach me a lot. ( and so hoping that when i've got a question. i could ask it here without getting any flaming on me or my english )

  8. #23
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,548
    Which compiler are you actually using?

    I've tried your code with 3 compilers (gcc, vc6, vc7) and I don't see the effect you're seeing.

    I see that -1 seems "special" in microsoft compilers, so that may be confusing you.

    With different return results, I see very different paths. The "jump" to what looks like an exception eventually leads to the return 0, which I figure is the "there is no exception" code being executed.

    Code:
    #include <iostream>
    using namespace std;
    
    	inline int my_strcpy(char* source, char* target){
    		int counter(0);
    		while (*target!=0){
    			*source++=*target++;
    			++counter;
    		}
    		*source = 0;
    		return counter+1;
    	}
    
    struct x {
        char ServerName[10];
        char MapName[10];
        char Game[10];
        char GameType[10];
        unsigned short PlayerCount;
        unsigned short MaxPlayers;
    };
    
    int foo ( char *bufptr, x *target ) {
    		try{
    			bufptr += my_strcpy(target->ServerName, bufptr);
    			bufptr += my_strcpy(target->MapName, bufptr);
    			bufptr += my_strcpy(target->Game, bufptr);
    			bufptr += my_strcpy(target->GameType, bufptr);
    			bufptr += 2; //Skip appid because it is no use to us
    			target->PlayerCount = static_cast<unsigned short>(*bufptr++);
    			target->MaxPlayers = static_cast<unsigned short>(*bufptr++);
    			bufptr+=3;
    		}
    		catch (std::bad_alloc&){
    			return -2;
    		}
    		catch(void *){
    			return -3;
    		}
        return 0;
    }
    
    int main ( ) {
        return 0;
    }
    
    // VC6 ASM
    // cl /Fafoo.s /GX foo.cpp
    ; Line 32
    	mov	eax, DWORD PTR _bufptr$[ebp]
    	add	eax, 3
    	mov	DWORD PTR _bufptr$[ebp], eax
    ; Line 34
    	jmp	SHORT $L7372
    $L8456:
    ; Line 35
    	mov	DWORD PTR $T8453[ebp], -2		; fffffffeH
    	mov	eax, $L8458
    	ret	0
    $L8458:
    	mov	eax, DWORD PTR $T8453[ebp]
    	jmp	SHORT $L7371
    $L8457:
    ; Line 38
    	mov	DWORD PTR $T8454[ebp], -3		; fffffffdH
    	mov	eax, $L8459
    	ret	0
    $L8459:
    	mov	eax, DWORD PTR $T8454[ebp]
    	jmp	SHORT $L7371
    $L7372:
    ; Line 40
    	mov	DWORD PTR __$EHRec$[ebp+12], -1
    	xor	eax, eax
    $L7371:
    ; Line 41
    	mov	ecx, DWORD PTR __$EHRec$[ebp+4]
    	mov	DWORD PTR fs:__except_list, ecx
    	pop	edi
    	pop	esi
    	pop	ebx
    	mov	esp, ebp
    	pop	ebp
    	ret	0
    
    // VC7 ASM
    ; Line 32
    	mov	eax, DWORD PTR _bufptr$[ebp]
    	add	eax, 3
    	mov	DWORD PTR _bufptr$[ebp], eax
    	jmp	SHORT $L9570
    $L9571:
    ; Line 35
    	mov	DWORD PTR $T9568[ebp], -2		; fffffffeH
    	mov	eax, $L9574
    	ret	0
    $L9572:
    ; Line 38
    	mov	DWORD PTR $T9569[ebp], -3		; fffffffdH
    	mov	eax, $L9576
    	ret	0
    $L9570:
    ; Line 39
    	mov	DWORD PTR __$EHRec$[ebp+12], -1
    ; Line 40
    	jmp	SHORT $L9575
    $L9576:
    ; Line 38
    	mov	eax, DWORD PTR $T9569[ebp]
    	jmp	SHORT $L8439
    $L9575:
    ; Line 40
    	jmp	SHORT $L9573
    $L9574:
    ; Line 35
    	mov	eax, DWORD PTR $T9568[ebp]
    	jmp	SHORT $L8439
    $L9573:
    ; Line 40
    	xor	eax, eax
    $L8439:
    ; Line 41
    	mov	ecx, DWORD PTR __$EHRec$[ebp+4]
    	mov	DWORD PTR fs:__except_list, ecx
    	pop	edi
    	pop	esi
    	pop	ebx
    	mov	esp, ebp
    	pop	ebp
    	ret	0
    PS
    Your English seems pretty reasonable to me
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  9. #24
    Registered User
    Join Date
    Mar 2006
    Posts
    725
    The dude was commenting on your spelling, not english in general. Just don't try to be l33t, c00l or vry bsy n huried.

    You should make it a point to write safe code and make as few assumptions as possible. If you use a fixed size buffer, make sure you don't try put in more than a fixed number of characters. Simple as that, but my_strcpy() seems to have a different agenda. C/C++ is very helpful in allowing you to trip up on seemingly trivial things, so it's really really important that you get things right the first time and not take any "shortcuts".
    Code:
    #include <stdio.h>
    
    void J(char*a){int f,i=0,c='1';for(;a[i]!='0';++i)if(i==81){
    puts(a);return;}for(;c<='9';++c){for(f=0;f<9;++f)if(a[i-i%27+i%9
    /3*3+f/3*9+f%3]==c||a[i%9+f*9]==c||a[i-i%9+f]==c)goto e;a[i]=c;J(a);a[i]
    ='0';e:;}}int main(int c,char**v){int t=0;if(c>1){for(;v[1][
    t];++t);if(t==81){J(v[1]);return 0;}}puts("sudoku [0-9]{81}");return 1;}

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. HELP with DX9 Errors!!!
    By Tommaso in forum Game Programming
    Replies: 7
    Last Post: 06-28-2006, 02:51 PM
  2. Errors with header files in OpenGL using VisualC++
    By wile_spice in forum Game Programming
    Replies: 3
    Last Post: 06-22-2006, 08:56 AM
  3. Weird Errors in VS 2003
    By Devil Panther in forum Windows Programming
    Replies: 1
    Last Post: 10-01-2005, 06:16 AM
  4. executing errors
    By s0ul2squeeze in forum C++ Programming
    Replies: 3
    Last Post: 03-26-2002, 12:43 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21