Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Why would this crash?

Reply
Thread Tools

Why would this crash?

 
 
JoeC
Guest
Posts: n/a
 
      04-15-2010
I found a flaw in my logic I was using a BYTE type rather than an int
type but when I changed the type the program fails. I do ensure that
the number is allowed by the size of the array. num is the number I
will modify in the array. I works when it is a BYTE type it crashes
with an int type.

void bitmap::changeBit(int ac, int dn, BYTE col){

int up = 16-dn;
int num = (up*acc)+(current*16)+ac;

if((num < acc*dwn) || (num > 0)){
bits[num] = col;
}else{ MessageBox(NULL, "bang!", "Info", MB_OK);}
}

acc and dwn are the size of the array. I am using a flat array to
represent 2d object. I am simply trying to change the elements int he
array.

Why would I get an error from an int and not from a BYTE?
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      04-15-2010
On Thu, 2010-04-15, Daniel T. wrote:
> JoeC <(E-Mail Removed)> wrote:
>
>> I found a flaw in my logic I was using a BYTE type rather than an int
>> type but when I changed the type the program fails.

>
> Along with what Paavo said, keep in mind that BYTE type is (in all
> likelihood,) an unsigned type, while int is not. Sign conversion might
> be causing problems in your code too.


To me, BYTE sounds signed -- with UBYTE as the unsigned version.
Maybe it's my Amiga programming background.

The *real* problem is of course that we have no way of knowing. Unless
it's a well-known Windows type or something.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
 
JoeC
Guest
Posts: n/a
 
      04-15-2010
On Apr 15, 11:01*am, Jorgen Grahn <(E-Mail Removed)> wrote:
> On Thu, 2010-04-15, Daniel T. wrote:
> > JoeC <(E-Mail Removed)> wrote:

>
> >> I found a flaw in my logic I was using a BYTE type rather than an int
> >> type but when I changed the type the program fails.

>
> > Along with what Paavo said, keep in mind that BYTE type is (in all
> > likelihood,) an unsigned type, while int is not. Sign conversion might
> > be causing problems in your code too.

>
> To me, BYTE sounds signed -- with UBYTE as the unsigned version.
> Maybe it's my Amiga programming background.
>
> The *real* problem is of course that we have no way of knowing. Unless
> it's a well-known Windows type or something.
>
> /Jorgen
>
> --
> * // Jorgen Grahn <grahn@ *Oo *o. * . *.
> \X/ * * snipabacken.se> * O *o * .



You do look familiar, I was an Amiga user until 2000. I wish I had
learned Amiga programming. I eventually had to get a PC because there
was too much I couldn't do.
 
Reply With Quote
 
JoeC
Guest
Posts: n/a
 
      04-15-2010
On Apr 15, 6:51*am, "Daniel T." <(E-Mail Removed)> wrote:
> JoeC <(E-Mail Removed)> wrote:
> > I found a flaw in my logic I was using a BYTE type rather than an int
> > type but when I changed the type the program fails.

>
> Along with what Paavo said, keep in mind that BYTE type is (in all
> likelihood,) an unsigned type, while int is not. Sign conversion might
> be causing problems in your code too.


I do realize that the sign conversiona and runnin over or under the
array can lead to problems. I do check for that.

I just used this:
BYTE num = (up*acc)+(current*16)+ac;

The program ran fine and with one block a 256 sized array it does not
crash. When I change BYTE to int it does crash. I do get stack
errors and debugging exceptions with the int.

I get a heap corruption with int and nothing with BYTE. The problem
is that BYTE only goes up to 256 and a larger number because my arrays
increase a 256 per added segment.
 
Reply With Quote
 
JoeC
Guest
Posts: n/a
 
      04-15-2010
thing can happen, including that the program can appear to work.
>
> You should indeed learn how to step through the program in the debugger
> and examine the variable values at each step. Then you could see by
> yourself where exactly the things are starting to deviate from what you
> expect.
>


Thanks for the suggestions.

 
Reply With Quote
 
James Lothian
Guest
Posts: n/a
 
      04-15-2010
JoeC wrote:
> I found a flaw in my logic I was using a BYTE type rather than an int
> type but when I changed the type the program fails. I do ensure that
> the number is allowed by the size of the array. num is the number I
> will modify in the array. I works when it is a BYTE type it crashes
> with an int type.
>
> void bitmap::changeBit(int ac, int dn, BYTE col){
>
> int up = 16-dn;
> int num = (up*acc)+(current*16)+ac;
>
> if((num< acc*dwn) || (num> 0)){
> bits[num] = col;
> }else{ MessageBox(NULL, "bang!", "Info", MB_OK);}
> }
>
> acc and dwn are the size of the array. I am using a flat array to
> represent 2d object. I am simply trying to change the elements int he
> array.
>
> Why would I get an error from an int and not from a BYTE?


Probably because the result of the indexing operation
(up*acc)+(current*16)+ac isn't representable in a BYTE
(whose range will probably be 0..255 or -128..127, depending
on signedness). The restricted range of BYTE presumably stops
the result of the indexing from walking off the end of the
allocated memory. Once you switch to using int, which has
much wider range, the result is representable and you are
indexing off the end of the memory and UB ensues. So, either
the indexing calculation is wrong, or the memory block isn't
as big as you thought it was. Trace through it with the debugger.

James

 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      04-15-2010
On 15 apr, 22:16, JoeC <(E-Mail Removed)> wrote:
> On Apr 15, 6:51*am, "Daniel T." <(E-Mail Removed)> wrote:
>
> > JoeC <(E-Mail Removed)> wrote:
> > > I found a flaw in my logic I was using a BYTE type rather than an int
> > > type but when I changed the type the program fails.

>
> > Along with what Paavo said, keep in mind that BYTE type is (in all
> > likelihood,) an unsigned type, while int is not. Sign conversion might
> > be causing problems in your code too.

>
> I do realize that the sign conversiona and runnin over or under the
> array can lead to problems. *I do check for that.
>
> I just used this:
> * * * * BYTE num = (up*acc)+(current*16)+ac;
>
> The program ran fine and with one block a 256 sized array it does not
> crash. *When I change BYTE to int it does crash. *I do get stack
> errors and debugging exceptions with the int.


I understand that bits are acc*dwn array. up is dwn-dn (you had
explicit 16 there but i feel you assume that dwn is 16). Other talks
indicate that the array size is 256 so probably that acc is also 16.

if to rewrite your formula using the assumptions above we get:
signed num = (up+current)*16 + ac;

So ... whenever dn < current it crashes. You tell no much about that
current, so no idea ... what it is.

 
Reply With Quote
 
JoeC
Guest
Posts: n/a
 
      04-16-2010


Thanks all for the help. It turns out that my function was giving me
negitave numbers and found and fixed them with the abs command.
 
Reply With Quote
 
Helge Kruse
Guest
Posts: n/a
 
      04-16-2010

"JoeC" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
>
> Thanks all for the help. It turns out that my function was giving me
> negitave numbers and found and fixed them with the abs command.


When your function was given negative numbers the contract to use this
function was probably violated. Are the arguments really "fixed" or are they
just move to any arbitrary values in the acceptable range?

You should consider to add an error check at the beginning of the function
if you can make sure that you get valid arguments. You dont need such a
check for each function. But at interface functions this might be necessary.

Helge


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
an oddball scary kind of thing you would think would never happen richard Computer Support 4 01-31-2010 06:34 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
IS-IS,why would you use this vs. others wysiwyg21 Cisco 4 02-03-2005 02:52 AM
Why would the library-activated serviced components put more load on db? =?Utf-8?B?U3Rhbg==?= ASP .Net 1 02-27-2004 12:19 PM



Advertisments