vm_alloc failure on os x?

Hi,

anyone out there using radzilla on os x, on a powerpc mac? I get the following:

powerbook:~/Desktop lars$ rzpict test.rzoct
*** malloc: vm_allocate(size=3221225472) failed (error code=3)
*** malloc[4717]: error: Can't allocate region
terminate called after throwing an instance of 'std::bad_alloc'
   what(): St9bad_alloc
Abort trap
powerbook:~/Desktop lars$

I get this error even on a scene containing only a box, so it is not scene-related. Is it possible that there are problems with endianess, size of datatypes, or anything not portable, in radzilla?

Ah, and it is not possible to compile with gcc-4.1. I use 3.3 instead (provided by apple).

CU Lars.

Lars O. Grobe wrote:

Hi,

anyone out there using radzilla on os x, on a powerpc mac? I get the following:

powerbook:~/Desktop lars$ rzpict test.rzoct
*** malloc: vm_allocate(size=3221225472) failed (error code=3)
*** malloc[4717]: error: Can't allocate region
terminate called after throwing an instance of 'std::bad_alloc'
  what(): St9bad_alloc

Hi Lars,

those problems on MAC OS X cause a lot of bad consciousness on my side, 'cause I know of them already for quite a time (Rob G reported similar errors last summer in the command line rzvu, but I thought that rzpict was working..
The weird thing is that I cannot reproduce them on Linux, and I don't have access to a Mac at the moment. (BTW anyone with a Mac living near Frankfurt ??? :slight_smile: ..

I would definitely like to sort this stuff out as soon as possible..

( By the way, radzilla expects at least some image sizes in a command, eg. your command: rzpict test.rzoct normally should spit out an illegal resolution error message...)

Concerning compiling with gcc 4.1: Do you have the output of the compilation error messages ? It would be nice if you could mail them to me so I can try to find some first clues about what could be wrong. The latest thing I corrected was to abide to the stricter namespace handling (two stage lookup) in derived template classes enforced with gcc 3.4.3, which differs from the manner written in my somewhat older C++ textbooks :slight_smile: ..So lets have a look what new gimmicks the gcc folks have now pulled out of their hats..

-Carsten

···

_______________________________________________
Radzilla mailing list
[email protected]
http://radiance-online.org/mailman/listinfo/radzilla

--
---------------------------------------------------------

"Der Deckel muß zugehen." (P.Kölsch)

---------------------------------------------------------

(BTW anyone with a Mac living near Frankfurt ??? :slight_smile: ..

Now that I moved from Darmstadt (30km from Frankfurt) to Istanbul (2000km
from Frankfurt)...

But I guess I can help you get access to some Macs in Darmstadt for
Development, ssh and/or physical access as long as you want to travel :wink:

The compile errors are caused by some strict checking of declarations in
gcc4 IMHO. So as far as I remember this won't work in another class (class
TestClass is defined somewhere before):

TestClass TestInstance;

But the following will:

Class TestClass;
TestClass TestInstance;

This is something that I do not really understand and might be related to
some new development in cpp-standards I am not aware of. But it appears in
lots of usenet posts :wink: I will send you the output of gcc tonight or
tomorrow.

CU Lars.

Lars Grobe wrote:

Now that I moved from Darmstadt (30km from Frankfurt) to Istanbul (2000km
from Frankfurt)...

But I guess I can help you get access to some Macs in Darmstadt for
Development, ssh and/or physical access as long as you want to travel :wink:

I know Darmastadt very well, that's definitely an option, I'll contact you off-list about this..

The compile errors are caused by some strict checking of declarations in
gcc4 IMHO. So as far as I remember this won't work in another class (class
TestClass is defined somewhere before):

../../base/scenebase.h:101: error: ISO C++ forbids declaration of 'SCENEIO_OC' with no type
../../base/scenebase.h:101: error: expected ';' before '*' token

Yepp, that seems to confirm your words above, apparently the stricter gcc 4 doesn't accept forward declarations
(or forward friend declarations) within a class body anymore ..

thanx again for the hint..

-Carsten

···

_______________________________________________
Radzilla mailing list
[email protected]
http://radiance-online.org/mailman/listinfo/radzilla

--
---------------------------------------------------------

"Der Deckel muß zugehen." (P.Kölsch)

---------------------------------------------------------

powerbook:~/Desktop lars$ rzpict test.rzoct
*** malloc: vm_allocate(size=3221225472) failed (error code=3)
*** malloc[4717]: error: Can't allocate region
terminate called after throwing an instance of 'std::bad_alloc'
  what(): St9bad_alloc

[...]

The scene I am loading is small, just a box. It should really not require the allocation of 3GB memory.

The problem seams to appear from HEADER::resize(), the output of gdb follows:

···

--
#0 0x94a182cc in malloc_printf ()
#1 0x9498b3d0 in allocate_pages ()
#2 0x94989530 in large_and_huge_malloc ()
#3 0x9497c1e8 in szone_malloc ()
#4 0x94979c18 in malloc_zone_malloc ()
#5 0x9497aa00 in malloc ()
#6 0x00cfa36c in operator new(unsigned long) (sz=3221224272) at ../../../../gcc-4.1-20050924/libstdc++-v3/libsupc++/new_op.cc:57
#7 0x00cfa4b4 in operator new[](unsigned long) (sz=2494221408) at ../../../../gcc-4.1-20050924/libstdc++-v3/libsupc++/new_opv.cc:37
#8 0x000035c8 in HEADER::resize() (this=0xbffffb50) at ../base/headerstuff.C:97
#9 0x000033a4 in HEADER::dump(char*) (this=0xbffff8f8, nwstr=0xbfffe6e0 ":-)RADZILLA\n") at ../base/headerstuff.C:42
#10 0x00003560 in HEADER::dumpheader(char*) (this=0xbffff8f8, fname=0xc <Address 0xc out of bounds>) at ../base/headerstuff.C:84
#11 0x00040f2c in main (argc=12, argv=0xbffff8f8) at ../ray/rzpict.C:82
--

BTW, why do I get references to gcc-4.1 libstdc++, I compiled with gcc-3.3 - might this be the reason for my problems? Or did others experience this bug on OS X with a clean installation (I use my own gcc-4.1 which might have broken the systems gcc-3 environment)?

CU Lars.

Hi Lars,

thanx very much for the debugging info !!!
I already assumed that the problem may have sth. to do with incorrectly initialized data , now I have a concrete starting point where to look for it.

BTW, why do I get references to gcc-4.1 libstdc++, I compiled with gcc-3.3 - might this be the reason for my problems? Or did others experience this bug on OS X with a clean installation (I use my own gcc-4.1 which might have broken the systems gcc-3 environment)?

I think that the radzilla error is an issue of - lets call it not 100% bullet-proof- programming on my side. Probably MacOSX tries to perform some sort of optimziation during allocation, which doesn't tolerate that in contrast to LInux which seems to be more lax in this respect. Just a theory..

That gcc lib issue has a different background: On installation, gcc defaultwise installs itself as the standard compiler and the universal library links alwas point to those from the latest installation. This of course has an effect also on other versions of gcc present on your system. You can configure gcc to automatically use a special set of standard libraries (glibc, libstc++) for linkage, which is more appropriate for the latter case. I once did that, but unfortunately have forgotten the exact procedure, so I cannot present it here on the fly . Anyway, I had it from the gcc documentation, but I remember that it was bit hidden in the vast amount of stuff to read..

-cb

···

CU Lars.

------------------------------------------------------------------------

_______________________________________________
Radzilla mailing list
[email protected]
http://radiance-online.org/mailman/listinfo/radzilla

--
---------------------------------------------------------

"Der Deckel muß zugehen." (P.Kölsch)

---------------------------------------------------------