Odd Linux & GCC behaviour

Odd Linux & GCC behaviour

Post by d.. » Wed, 21 Jul 1993 22:13:35



Hi,
        I was compiling an X program called xpaint the other day when I
ran into some (to me) inexplicable behaviour. Every thing was going ok
until gcc started to compile tif_fax3.c. It got stuck on this one for a
long time and I couldn't do anything else on the system. I tried it in
X and I couldn't move the mouse or bring up other windows. I tried it in
character mode and I couldn't login on another vc.

        I then tried to find out what is causing this behaviour. It was
that tif_fax3.c includes a huge include file (~400k) that contains an
intialized matrix ([25][256]). Well, I'm surprised because:

        - Why should gcc spend so much time processing the matrix (half
          an hour before I killed it). Obviously it is doing some kind of
          optimization but what?
        - Whatever gcc is up to, I expect a preemptive multi-tasking system
          to allow me to do other things while gcc is chugging along.

        My system is a 486 sx/25 clone with 16mb RAM, using linux99pl10
and gcc 2.3.3.

Any enlightening comments will be appreciated.

--

 
 
 

Odd Linux & GCC behaviour

Post by Drew Eckhar » Thu, 22 Jul 1993 20:20:29



>Hi,
>    I was compiling an X program called xpaint the other day when I
>ran into some (to me) inexplicable behaviour. Every thing was going ok
>until gcc started to compile tif_fax3.c. It got stuck on this one for a
>long time and I couldn't do anything else on the system. I tried it in
>X and I couldn't move the mouse or bring up other windows. I tried it in
>character mode and I couldn't login on another vc.
>    I then tried to find out what is causing this behaviour. It was
>that tif_fax3.c includes a huge include file (~400k) that contains an
>intialized matrix ([25][256]). Well, I'm surprised because:

>    - Why should gcc spend so much time processing the matrix (half
>      an hour before I killed it). Obviously it is doing some kind of
>      optimization but what?
>    - Whatever gcc is up to, I expect a preemptive multi-tasking system
>      to allow me to do other things while gcc is chugging along.

>    My system is a 486 sx/25 clone with 16mb RAM, using linux99pl10
>and gcc 2.3.3.

There is a bug in GCC that will cause it to use incredible amounts
of memory when compiling large initialized arrays (I've seen
cases where it's used 25M of virtual memory).

With your version of Linux, sbrk() never fails. (this has
been fixed, Linux .99.11 tries to figure out how much memory
will be used once everything page faults in and will cause sbrk()
to fail when it thinks you'll run out of memory).  As the number of
free swap pages gets smaller and smaller, Linux thrashes harder and
gets slower - after a few hours, the offending process will recieve
a SIGSEGV.

Upgrade to Linux .99.11, or use apropriate rlimits to insure that
you don't run out of memory.  If your programs run out of
memory, add more swap.
--
Boycott USL/Novell for their absurd anti-BSDI lawsuit. |
Condemn Colorado for Amendment Two.                    | Drew Eckhardt

Will administer Unix for food                          |

 
 
 

Odd Linux & GCC behaviour

Post by d.. » Fri, 23 Jul 1993 23:34:15


Thanks for all of those who e-mailed with clarifications. I recieved about
15 messages on the subject and there is a consensus on the following:

- It is primarily a GCC 2.3.3 problem. It needs huge amounts of memory when
  processing initialized arrays. The problem is corrected in later releases,
  2.4.3+
- It is partially Linux's memory management fault in that it allows one process
  to hog memory thus giving the impression that multi-tasking is not running
  as expected. If linux limited per process memory, GCC would abort due to
  lack of VM before it exhausts system resources. I got the impression that
  this is different in linux99pl11 but I'm not sure.
- It is partially my fault becuse I had not created swap space. I expected
  16 MB to to be enough for my requirements. I'll make a swap file RSN.

Hope this helps,

--

+---------------------------------+

 
 
 

1. odd gcc (2.3.3) behavior

As the subject says, gcc (2.3.3) is being strange.

I have been playing around with a bunch of different languages lately
so that when I was writing a little c program the other day I totally
thrashed the syntax and gcc didn't mind.  Specifically I had blocks
within blocks (at least that is what I think it is called) like:

        main()
        ...
                void some_procedure()
        ...
                void another_procedure()

gcc accepted this.  I think this is odd.

Sabina

2. socket interface library

3. i810-tco : odd behavior, odd driver ?

4. Solaris 2.5 x86 cannot boot

5. Reload /etc/resolv.conf w/out reboot & odd natd behavior

6. Enlightenment Configuration

7. Odd tcsh behaviour: subshells & stdout

8. Partitioning HDD

9. odd behaviour of "pwd" & "df" after Live Upgrade?

10. Odd behavior--Linux-Mandrake 7.2

11. odd 100BaseT Linux/Win95 behavior

12. Large memory oops/odd behaviour Linux 2.2, seeking recommendations

13. Compaq Prosignia 150 & Linux & Strange behavior