* [rfc patch] nomem: internal_error -> error
@ 2010-06-01 16:48 Jan Kratochvil
2010-06-01 17:56 ` Mark Kettenis
0 siblings, 1 reply; 3+ messages in thread
From: Jan Kratochvil @ 2010-06-01 16:48 UTC (permalink / raw)
To: gdb-patches
Hi,
unfortunately I see this problem reproducible only with the
archer-jankratochvil-vla branch (VLA = Variable Length Arrays - char[var]).
OTOH this branch I hopefully submit in some form for FSF GDB later.
In this case (a general problem but tested for example on Fedora 13 i686):
int
main (int argc, char **argv)
{
char a[argc];
return a[0];
}
(gdb) start
(gdb) print a
../../gdb/utils.c:1251: internal-error: virtual memory exhausted: can't allocate 4294951689 bytes.
It is apparently because boundary for the variable `a' is not initialized
there. Users notice it due to Eclipse-CDT trying to automatically display all
the local variables on each step.
Apparentl no regressions on {x86_64,x86_64-m32,i686}-fedora13-linux-gnu.
But is anone aware of the reasons to use internal_error there?
I find simple error as a perfectly reasonable there.
(history only tracks it since the initial import)
IIRC this idea has been discussed with Tom Tromey, not sure of its origin.
I understand it may be offtopic for FSF GDB but from some GDB crashes I am not
sure if it can happen only due to the VLA variables.
Thanks,
Jan
gdb/
2010-06-01 Jan Kratochvil <jan.kratochvil@redhat.com>
Tom Tromey <tromey@redhat.com>
* utils.c (nomem): Change internal_error to error.
--- a/gdb/utils.c
+++ b/gdb/utils.c
@@ -1265,15 +1265,9 @@ void
nomem (long size)
{
if (size > 0)
- {
- internal_error (__FILE__, __LINE__,
- _("virtual memory exhausted: can't allocate %ld bytes."),
- size);
- }
+ error (_("virtual memory exhausted: can't allocate %ld bytes."), size);
else
- {
- internal_error (__FILE__, __LINE__, _("virtual memory exhausted."));
- }
+ error (_("virtual memory exhausted."));
}
/* The xmalloc() (libiberty.h) family of memory management routines.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [rfc patch] nomem: internal_error -> error
2010-06-01 16:48 [rfc patch] nomem: internal_error -> error Jan Kratochvil
@ 2010-06-01 17:56 ` Mark Kettenis
2010-06-01 17:58 ` Jan Kratochvil
0 siblings, 1 reply; 3+ messages in thread
From: Mark Kettenis @ 2010-06-01 17:56 UTC (permalink / raw)
To: jan.kratochvil; +Cc: gdb-patches
> Date: Tue, 1 Jun 2010 18:48:08 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
>
> Hi,
>
> unfortunately I see this problem reproducible only with the
> archer-jankratochvil-vla branch (VLA = Variable Length Arrays - char[var]).
> OTOH this branch I hopefully submit in some form for FSF GDB later.
>
> In this case (a general problem but tested for example on Fedora 13 i686):
>
> int
> main (int argc, char **argv)
> {
> char a[argc];
> return a[0];
> }
>
> (gdb) start
> (gdb) print a
> ../../gdb/utils.c:1251: internal-error: virtual memory exhausted: can't allocate 4294951689 bytes.
>
> I find simple error as a perfectly reasonable there.
I disagree; this internal-error really is a bug in GDB. We should
never try to allocate that much memory.
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [rfc patch] nomem: internal_error -> error
2010-06-01 17:56 ` Mark Kettenis
@ 2010-06-01 17:58 ` Jan Kratochvil
0 siblings, 0 replies; 3+ messages in thread
From: Jan Kratochvil @ 2010-06-01 17:58 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb-patches
On Tue, 01 Jun 2010 19:55:40 +0200, Mark Kettenis wrote:
> > (gdb) print a
> > ../../gdb/utils.c:1251: internal-error: virtual memory exhausted: can't allocate 4294951689 bytes.
> >
> > I find simple error as a perfectly reasonable there.
>
> I disagree; this internal-error really is a bug in GDB. We should
> never try to allocate that much memory.
So that even if the object is really so large in the inferior GDB should be
fixed to read+process the object in multiple parts? That makes sense.
Thanks,
Jan
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-06-01 17:58 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-01 16:48 [rfc patch] nomem: internal_error -> error Jan Kratochvil
2010-06-01 17:56 ` Mark Kettenis
2010-06-01 17:58 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox