Cannot Malloc, with 430 megs of RAM available + 1gig Swap

Kevin Day msu-kday at student.mcneese.edu
Mon Nov 28 07:50:45 PST 2005


First, there is one important aspect that needs to be known:
I am using a uClibc system and the result of which could be my problem instead.
Despite this, this problem has only been noticed so far in Xorg-modular, so I
suspect it is either Xorg-Modular or a combination of Xorg & uClibc-0.9.28.
-----
originally, I had an entirely PIC based system, which resulted in 40 less megs
of RAM being used..vs the 80megs the non-PIC based uses.
Under the PIC based system, Xorg would simply stop during the load process and
never return my blank monitor screen to the console, so I had to manually
reboot or ssh-reboot the machine. (no error messages in the Xorg log files)

Having no clue what the problem was, I eventually compiled a non-PIC based
system..

It had trouble compiling, could not find "assert" during the linking progress
in many of the files, namely the glx files.
So I added the "#include <assert.h>" to the glx files...not one improvement.
After looking into my libc's assert.h header file, I noticed that they used a
#define to declare what assert is.
So, for testing purposes I copied their "no_debug" version which pretty much
was a single line that was something like the following: #define assert
((void),0).
I then added:
#ifndef assert
#define assert ((void),0)
#endif
to each of the files that donot compile as a result of this.
My end result was a partially working Xorg. However, any program that I did not
patch that somehow still compiled seem to have problems still.

These programs return "Cannot call assert"
With further study on my PIC based system after this, I was able to identify
the same kind of error, using an bug exploit in qingy to get my screen back.

Any ideas?  I would rather not use that hack to get xorg and assert to compile
togethor.
-- 


More information about the xorg-modular mailing list