octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: segmentation fault when load more then 2.1 GB


From: Daniel Heiserer
Subject: Re: segmentation fault when load more then 2.1 GB
Date: Wed, 6 Oct 2004 10:52:34 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030212

address@hidden wrote:
On  6-Oct-2004, Daniel Heiserer <address@hidden> wrote:

| At least one object is larger then 2GB. I submitted a patch on February | 12th 2003 which fixes that problem. I never got a feedback concerning | the question for the "adverse effects" also I haven't seen the patch | included till today. Unfortunately the people answering the thread | focused on the bad timing of the "rand" function I used to demonstrate | the usage :-( | | The patch was:
| http://www.octave.org/octave-lists/archive/bug-octave.2003/msg00306.html

Your one-line change only allowed the >2GB allocation to succeed.
After that, you would surely run into some problems with indexing,
etc.

| I am willing to help fixing all this "size" limitations quickly.

Please see the recent discussion on the help list with the subject
"matrix sizes".

Did anyone create now an octave_idx or is there an agreement howto implement a typedef for the indexing?
I cannot do this.
I could start crawling through the libraries and change them to this index-type once the core maintainers made up the starting decision howto do this. I would suggest that (one of) the next beta version has this
type defined.
I also suggest we do the same for the filepointer stuff. So we can adress the big stuff and make it configurable before the compilation. It shouldn't be that a big deal to write a check routine which includes compiling and allocating and adressing these large entities.

-- daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]