malloc(0) during exception throw & catch

malloc(0) during exception throw & catch

[Denis Perchine]

Hello,

Small test:

#include <exception>

void bad() {
  throw exception();
}

int main() {
    try {
      bad();
    } catch (exception &) {
    }
  return 0;
}

And all memory races detection tools says that there is call of malloc(0) inside it.
Is there any reasonable explanations to this?

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Re: malloc(0) during exception throw & catch

[Martin v. Loewis]

> And all memory races detection tools says that there is call of
> malloc(0) inside it.

Thanks for your bug report. You did not mention what platform you are
using, so it is hard to reproduce the problem. I could not reproduce
it on i586-pc-linux-gnu, with gcc 2.95.2.

Regards,
Martin

Re: malloc(0) during exception throw & catch

[Denis Perchine]

> > And all memory races detection tools says that there is call of
> > malloc(0) inside it.
> 
> Thanks for your bug report. You did not mention what platform you are
> using, so it is hard to reproduce the problem. I could not reproduce
> it on i586-pc-linux-gnu, with gcc 2.95.2.

gcc-2.95.2. i686-linux. 2.2.15.

Exception SHOULD be derived from exception.

#include <stdio.h>
#include <exception>

class ex : public exception {
public:
  ex() : exception() {};
};

int main() {
  try {
    throw ex();
  } catch (ex &x) {
    fprintf(stderr, "ex catched\n");
  }

  return 0;
}

Compile it with -g option (this is obligatory. Somehow without debug info all is OK).
And use for example YAMD ( http://www3.hmc.edu/~neldredge/yamd/ )

run-yamd -l 2 -o a ./ex

And you will get:

YAMD version 0.32
Starting run: ./ex
Executable: /home/dyp/tmp/throw/ex
Virtual program size is 1472 K
Time is Sun May 28 06:10:27 2000

default_alignment = 1
min_log_level = 2
repair_corrupted = 0
die_on_corrupted = 1
check_front = 0

WARNING: Zero-byte allocation
Address 0x2ac23000, size 0
Allocated by malloc at
        /lib/libc.so.6(malloc+0x2e)[0x2ab88ede]
        /usr/lib/libstdc++-libc6.1-2.so.3(_._13bad_exception+0x46e)[0x2ab04b92]
        /usr/lib/libstdc++-libc6.1-2.so.3(_._13bad_exception+0x574)[0x2ab04c98]
        /usr/lib/libstdc++-libc6.1-2.so.3(__frame_state_for+0x23)[0x2ab05497]
        /usr/lib/libstdc++-libc6.1-2.so.3(__throw+0x67)[0x2ab03bef]
        /home/dyp/tmp/throw/ex.cpp:12(main)[0x8048943]
        /lib/libc.so.6(__libc_start_main+0x115)[0x2ab4fd69]
        ??:0(_start)[0x8048811]

WARNING: Zero-byte allocation
Address 0x2ac25000, size 0
Allocated by malloc at
        /lib/libc.so.6(malloc+0x2e)[0x2ab88ede]
        /usr/lib/libstdc++-libc6.1-2.so.3(_._13bad_exception+0x47a)[0x2ab04b9e]
        /usr/lib/libstdc++-libc6.1-2.so.3(_._13bad_exception+0x574)[0x2ab04c98]
        /usr/lib/libstdc++-libc6.1-2.so.3(__frame_state_for+0x23)[0x2ab05497]
        /usr/lib/libstdc++-libc6.1-2.so.3(__throw+0x67)[0x2ab03bef]
        /home/dyp/tmp/throw/ex.cpp:12(main)[0x8048943]
        /lib/libc.so.6(__libc_start_main+0x115)[0x2ab4fd69]
        ??:0(_start)[0x8048811]

*** Finished at Sun May 28 06:10:27 2000
Allocated a grand total of 9104 bytes
8 allocations
Average of 1138 bytes per allocation
Max bytes allocated at one time: 9080
96 K alloced internally / 64 K mapped now / 36 K max
Virtual program size is 1588 K
End.

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Re: malloc(0) during exception throw & catch

[Martin v. Loewis]

> > Thanks for your bug report. You did not mention what platform you are
> > using, so it is hard to reproduce the problem. I could not reproduce
> > it on i586-pc-linux-gnu, with gcc 2.95.2.
> 
> gcc-2.95.2. i686-linux. 2.2.15.
[...]
> And use for example YAMD ( http://www3.hmc.edu/~neldredge/yamd/ )

Ok. I think I found the cause, it is in gcc/frame.c

static inline void
start_fde_sort (fde_accumulator *accu, size_t count)
{
  accu->linear.array = (fde **) malloc (sizeof (fde *) * count);
  accu->erratic.array = (fde **) malloc (sizeof (fde *) * count);
  accu->linear.count = 0;
  accu->erratic.count = 0;
}

If count is zero, it will call malloc with a size of zero. This is in
turn called from fde_init. If you think this is a problem, please
submit a patch to gcc-patches@gcc.gnu.org.

Regards,
Martin

Re: malloc(0) during exception throw & catch

[Marc Espie]

In article <200005281058.MAA05095@loewis.home.cs.tu-berlin.de> you write:
>If count is zero, it will call malloc with a size of zero. This is in
>turn called from fde_init. If you think this is a problem, please
>submit a patch to gcc-patches@gcc.gnu.org.


There is already code in libgcc (new*) that does assume malloc(0) and
free(NULL) are bad things.

I've been toying with a patch that would add t-fragments defines
(HAVE_SANE_MALLOC and HAVE_SANE_FREE) to avoid those extra tests,
since on many modern platforms, malloc(0) works, and free(NULL) as well.

Would you think it a good idea to extend the patch to cover the case that's
mentionned in this thread ?

Re: malloc(0) during exception throw & catch

[Denis Perchine]

> >If count is zero, it will call malloc with a size of zero. This is in
> >turn called from fde_init. If you think this is a problem, please
> >submit a patch to gcc-patches@gcc.gnu.org.
> 
> There is already code in libgcc (new*) that does assume malloc(0) and
> free(NULL) are bad things.
> 
> I've been toying with a patch that would add t-fragments defines
> (HAVE_SANE_MALLOC and HAVE_SANE_FREE) to avoid those extra tests,
> since on many modern platforms, malloc(0) works, and free(NULL) as well.

This does not matter... Problem is that it is impossible or very hard to use
memory debuging tools when core libraries have such bugs inside.
 
> Would you think it a good idea to extend the patch to cover the case that's
> mentionned in this thread ?

Why not. The only thing I would like to see is that this will be turned off by default.
BTW, I've submitted a patch to gcc-patches for this problem and did not have any
reply for 2 weeks. Is this usual way of gcc team work?

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Re: malloc(0) during exception throw & catch

[Marc Espie]

In article < 0006080203200C.00505@dyp > you write:
>BTW, I've submitted a patch to gcc-patches for this problem and did not have any
>reply for 2 weeks. Is this usual way of gcc team work?

Yes, some stuff is more sexy than others.
I've had patches sit untouched on the mailing-list for over two months,
at which time they of course no longer work, since the core has moved
beyond that.

I've also had bug reports sit for a long time. Try non-sexy, as in
non-linux, non-elf, non-i386, and you may have to wait for a looong
time.

Re: malloc(0) during exception throw & catch

[H . J . Lu]

On Thu, Jun 08, 2000 at 12:33:39AM +0200, Marc Espie wrote:
> In article < 0006080203200C.00505@dyp > you write:
> >BTW, I've submitted a patch to gcc-patches for this problem and did not have any
> >reply for 2 weeks. Is this usual way of gcc team work?
> 
> Yes, some stuff is more sexy than others.
> I've had patches sit untouched on the mailing-list for over two months,
> at which time they of course no longer work, since the core has moved
> beyond that.

Agreed.

> 
> I've also had bug reports sit for a long time. Try non-sexy, as in
> non-linux, non-elf, non-i386, and you may have to wait for a looong
> time.

I am using Linux/ELF/ia32 and I am in the same boat as you.



H.J.

Patch reviewal (was: malloc(0) during exception throw & catch)

[Gerald Pfeifer]

On Thu, 8 Jun 2000, Marc Espie wrote:
> Yes, some stuff is more sexy than others.
> I've had patches sit untouched on the mailing-list for over two months,
> at which time they of course no longer work, since the core has moved
> beyond that.

Patches should never remain unreviewed for that long a period. Of course
it may happen that a patch falls through the cracks, in which case a
reminder after one month or so seems useful, but two months is a bit
long.

Of course, we are a volunteer project, and considering that, it works
amazingly well, but when it comes to BSD-specific patches, for example,
Jeff is usually the only one taking care of them.

Perhaps we need additional maintainers to take care of "non-sexy" stuff?

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: malloc(0) during exception throw & catch

[Denis Perchine]

> >BTW, I've submitted a patch to gcc-patches for this problem and did not have any
> >reply for 2 weeks. Is this usual way of gcc team work?
> 
> Yes, some stuff is more sexy than others.
> I've had patches sit untouched on the mailing-list for over two months,
> at which time they of course no longer work, since the core has moved
> beyond that.
> 
> I've also had bug reports sit for a long time. Try non-sexy, as in
> non-linux, non-elf, non-i386, and you may have to wait for a looong
> time.

I do not know why it is unsexy... But from my point of view this is a major bug.
And even if patch is one line, it is still a major bug and it should have the highest
priority.

-- 
Sincerely Yours,
Denis Perchine

----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------

Re: malloc(0) during exception throw & catch

[Philipp Thomas]

* Marc Espie (espie@quatramaran.ens.fr) [20000608 00:34]:

> Try non-sexy, as in non-linux, non-elf, non-i386, and you may have to wait
> for a looong time.

Pardon me, but IMO this is a bit overly simplificating things, at least the
non-sexy part (I for instance wouldn't really call the NLS suff sexy :). For
the rest I tend to agree though. The reason is simply that there are few
people that both have the knowledge *and* the power to review and accept
patches. Add to that the fact that this work is mostly done on a voluntary
basis and you have all it takes for bottlenecks to come into existance :(

And even if because of some miracle many people would suddenly volunteer to
take over responsibility for certain parts of GCC, that wouldn't change
things over night, as my experience with the NLS stuff tells me. It does
require quite a bit of time (and dedication) to work your way into GCC and
its sometimes not exactly straight forward ways of dealing with things.

cherio
Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h