strange behaviour

strange behaviour

Post by Ionut Georgesc » Tue, 24 Apr 2001 18:19:36



Hi,

I am writing a libVL app with libIL, libGL and other libraries. For 4-5
days everything used to work fine. However, now it crashes like hell. I
have retrieved an older, working version from the CVS. Again, crashes over
crashes. It looks like the problems are in 'internal' calls to memcpy,
malloc, memfree and other *mem* functions. By internal I mean that the
program crashes in middle of a harmless jpeg_file = new ilImgFile(), when
__malloc or other functions alike ar called.

I have done a "complete reinstall" of the system. (keep *; install S; go;
at the inst prompt). Nothing changed. Do you have other ideas ?

Thanks a lot,
Ionut

***************
* Ionut Georgescu
* http://www.physik.tu-cottbus.de/~george/
* ICQ: 38973105
* "In Windows you can do everything Microsoft wants you to do; in Unix you
*                can do anything the computer is able to do."

 
 
 

strange behaviour

Post by César Blecua Udía » Tue, 24 Apr 2001 18:47:37



> Hi,

> I am writing a libVL app with libIL, libGL and other libraries. For 4-5
> days everything used to work fine. However, now it crashes like hell. I
> have retrieved an older, working version from the CVS. Again, crashes over
> crashes. It looks like the problems are in 'internal' calls to memcpy,
> malloc, memfree and other *mem* functions. By internal I mean that the
> program crashes in middle of a harmless jpeg_file = new ilImgFile(), when
> __malloc or other functions alike ar called.

The fact that it crashes in those functions doesn't mean they are
causing the problem. It's very possible that you've pointer related
problems somewhere in your code.

Try using a product for debugging memory problems. If you don't have
one, a good free example to start with is the Electric Fence library.
Just relink your software with that library (no changes needed in your
source code), and your program will (hopefully) crash in the first line
of code with illegal memory operations.

Note however that big programs are hard to debug with Electric Fence: If
it isn't little, you may need to enlarge your swap area (Electric Fence
allocates extra memory for every malloc call), and if it has a GUI, it
may take many minutes before you see the main window appear.

Btw, I don't remember where I downloaded Electric Fence from, but it
should be easy to locate on the net.

Another good idea is to run the program on other IRIX versions (if you
have several machines): It may crash in a different place (if you're
lucky), so you can have extra clues in your bug hunting session.

Hope you find your bad pointer,

Csar

Quote:

> I have done a "complete reinstall" of the system. (keep *; install S; go;
> at the inst prompt). Nothing changed. Do you have other ideas ?

> Thanks a lot,
> Ionut

> ***************
> * Ionut Georgescu
> * http://www.physik.tu-cottbus.de/~george/
> * ICQ: 38973105
> * "In Windows you can do everything Microsoft wants you to do; in Unix you
> *                can do anything the computer is able to do."


 
 
 

strange behaviour

Post by Ionut Georgesc » Tue, 24 Apr 2001 22:54:17


Ionut Georgescu sends greetings to Csar Blecua Udas

OK, I'll give the beast a try :)) What I hate at most is that the version
that used work perfectly until 4 days ago doesn't work anymore. I have
tried out all the versions from the CVS.

AND, can a pointer related problem crash with SIGSEGV or SIGBUS ?

Regards,
Ionut

>The fact that it crashes in those functions doesn't mean they are
>causing the problem. It's very possible that you've pointer related
>problems somewhere in your code.

>Try using a product for debugging memory problems. If you don't have
>one, a good free example to start with is the Electric Fence library.
>Just relink your software with that library (no changes needed in your
>source code), and your program will (hopefully) crash in the first line
>of code with illegal memory operations.

>Note however that big programs are hard to debug with Electric Fence: If
>it isn't little, you may need to enlarge your swap area (Electric Fence
>allocates extra memory for every malloc call), and if it has a GUI, it
>may take many minutes before you see the main window appear.

>Btw, I don't remember where I downloaded Electric Fence from, but it
>should be easy to locate on the net.

>Another good idea is to run the program on other IRIX versions (if you
>have several machines): It may crash in a different place (if you're
>lucky), so you can have extra clues in your bug hunting session.

>Hope you find your bad pointer,

>Csar

>> I have done a "complete reinstall" of the system. (keep *; install S; go;
>> at the inst prompt). Nothing changed. Do you have other ideas ?

>> Thanks a lot,
>> Ionut

>> ***************
>> * Ionut Georgescu
>> * http://www.physik.tu-cottbus.de/~george/
>> * ICQ: 38973105
>> * "In Windows you can do everything Microsoft wants you to do; in Unix you
>> *                can do anything the computer is able to do."

***************
* Ionut Georgescu      
* http://www.physik.tu-cottbus.de/~george/
* ICQ: 38973105
* "In Windows you can do everything Microsoft wants you to do; in Unix you
*                can do anything the computer is able to do."
 
 
 

strange behaviour

Post by Walter Robers » Wed, 25 Apr 2001 00:03:46




:AND, can a pointer related problem crash with SIGSEGV or SIGBUS ?

Yes, definitely!

You'd get SIGBUS if you used an odd address (last bit set) for any
instruction except the ones specific for non-aligned addresses.
You'd also get SIGBUS if in the kernel you manage to refer to an
address that doesn't physically exist (ie. no backing RAM for a
non-virtual fetch, or attempt to access an address in the I/O page
that has no associated device.)

You'd get SIGSEGV if you attempt to access an address in user
mode that you haven't been granted that kind of access to. (e.g.,
attempt to use a wild pointer, or run off the top of the stack.)

Both of these problems can crop up suddenly and intermittently if
you are using an uninitialized value, as you might not always get
the same value. C and C++ and F77 and F90 only make promises about
zeroing uninitialized values for some kinds of variables, and IRIX
does NOT automatically zero all virtual storage.

Another way that the problem can crop up suddenly would be if your
code attempts to allocate (e.g. malloc) the wrong size and sometimes
that memory is available and sometimes it isn't. If you aren't testing
the return value of every malloc() and are not using exceptions, then
you could easily end up attempting to access a large offset relative
to the null pointer; often this will end up in a segment of memory
you haven't been given access to.

 
 
 

1. Strange behaviour of text in POV

I rendered a few scenes with the same text-object repeated
a number of times, but otherwise with the same settings.
This is what I got:

 1 text-object:    69 seconds
 2 text-objects:  137 seconds
 3 text-objects:    3 seconds
 4 text-objects:    3 seconds

and so on. Does anyone know what's going on?

(I used POV 3.02 in DOS, BTW - nothing like good old-fashioned
'tracing, and if speed is indeed inversely proportional to the
complexity of the scene, so much better)

/www.Hexmaster.com

2. Nature and landscape site

3. Strange behaviour of PowerPC PS2.5.1 Plug-In

4. PSP size change

5. dmconvert: Strange behaviour

6. Direct3D7 ColorKey???

7. ImageVision: strange behaviour with ilImgStat

8. strange behaviour?

9. Video post strange behaviour?

10. Leapfrog algorithm for making 3D circles, has strange behaviour

11. Strange behaviour from gluProject???

12. Strange behaviour during hardware mode