On Sun, Feb 19, 2017 at 1:33 AM, Jeffrey Bouquet
wrote:
> I've a custom kernel r313487 without, and
> another with, debugging lines re-added.
> [ i386 ]
>
> With daily vmcore in /var/crash from the
> former, can the latter be used with GDB
> [ the larger kernel ] to evaluate the
> core file from t
On 2014-03-19 23:03, Nilton Jose Rizzo wrote:
> I have problem with debug some files compiled with clang, my gbd from system
> is 6.1.1, like showed.
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
On Mon, Nov 25, 2013 at 07:35:27PM +0200, Konstantin Belousov wrote:
> Could you update your gdb patch to use the KERN_PROC_SIGTRAMP from
> the patch below ? If this works out, I will add initialization of
> sv_szsigcode for ABIs which do not use shared page.
Below is the complete patch. With it
On Mon, Nov 25, 2013 at 12:13:53PM +0200, Andriy Gapon wrote:
>
> It seems that placement of signal trampolines was changed a while ago.
> Possibly
> with the introduction of the shared page, but I am not sure.
> Unfortunately, neither the gdb in base nor the ports gdb were updated to
> account
Date: Sun, 13 Jul 2003 16:49:12 -0700
From: "David O'Brien" <[EMAIL PROTECTED]>
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
>Date: Fri, 11 Jul 2003 15:50:02 -0700
>From: Marcel Moolenaar <[EMAIL PROTECTED]>
>
>Gang,
>
>With the gcc(1)
On Sun, Jul 13, 2003 at 02:28:08PM -0500, Mark Linimon wrote:
> > FSF GDB releases use a libbfd that's basically a
> > snapshot taken at the point where the release branch was cut.
>
> Hmm, seems like a motivation for a libbfd port that tracks the
> snapshot, for this very reason.
NO!
--
-- Da
On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote:
>Date: Sat, 12 Jul 2003 13:39:30 -0700
>From: Marcel Moolenaar <[EMAIL PROTECTED]>
>
>On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
>>
>>o We still have the Alpha gdb -k bug moved over from th
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
>Date: Fri, 11 Jul 2003 15:50:02 -0700
>From: Marcel Moolenaar <[EMAIL PROTECTED]>
>
>Gang,
>
>With the gcc(1) dust not even settled yet, I like to get some feedback
>on gdb(1). AFAICT, this is the deal:
>
>o
> FSF GDB releases use a libbfd that's basically a
> snapshot taken at the point where the release branch was cut.
Hmm, seems like a motivation for a libbfd port that tracks the
snapshot, for this very reason.
mcl
___
[EMAIL PROTECTED] mailing list
htt
On Sun, Jul 13, 2003 at 05:57:34PM +0200, Mark Kettenis wrote:
>
>> A1 If having support for amd64 is a major reason for doing a new
>>import of GDB, importing the upcoming GDB 6.0 would make more sense
>>to me.
>
>No ia64 is the major reason :-)
>
> Hmm. I think I just
Date: Sat, 12 Jul 2003 13:39:30 -0700
From: Marcel Moolenaar <[EMAIL PROTECTED]>
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
>
>o We still have the Alpha gdb -k bug moved over from the 5.1 todo
> list to the 5.2 todo list. I think this is "just" a b
On Sat, Jul 12, 2003 at 01:05:00PM +0200, Mark Kettenis wrote:
>
>o We still have the Alpha gdb -k bug moved over from the 5.1 todo
> list to the 5.2 todo list. I think this is "just" a bug fix.
>
> I'm not really familliar with the support for debugging FreeBSD
> kernels in GDB since
Date: Fri, 11 Jul 2003 15:50:02 -0700
From: Marcel Moolenaar <[EMAIL PROTECTED]>
Gang,
With the gcc(1) dust not even settled yet, I like to get some feedback
on gdb(1). AFAICT, this is the deal:
o Both ia64 and amd64 need gdb(1) support before they can become a
tier 1 pl
Marcel Moolenaar wrote:
> I'd say: upgrade gdb(1) and add support for ia64 and amd64, as well
> as make sure we fix any known showstopper bugs we know of.
[ ... ]
> Thoughts?
Will remote source level kernel debugging continue to work?
-- Terry
___
[EMAI
On Monday 10 March 2003 17:28, Dag-Erling Smorgrav wrote:
> Jun Su <[EMAIL PROTECTED]> writes:
> > To help myself more easily check the kernel dump, I added two new
> > command. One is ps, the other is kldstat. I know we can print the kernel
> > data manually to get the same information. I still th
Jun Su <[EMAIL PROTECTED]> writes:
> To help myself more easily check the kernel dump, I added two new command. One
> is ps, the other is kldstat. I know we can print the kernel data manually to
> get the same information. I still think this is useful. This can help the
> newbies to get the info
In message <[EMAIL PROTECTED]>, Robe
rt Watson writes:
>
>While debugging the recent pthreads problem, I've started running into
>this:
>
>pid 663 (test), uid 1000: exited on signal 10 (core dumped)
>failed to set signal flags properly for ast()
>failed to set signal flags properly for ast()
>faile
On Tue, 5 Nov 2002, Archie Cobbs wrote:
> Nate Lawson writes:
> > I've put together a patch that enables a kernel on the target machine to
> > detect a GDB packet and automatically enter GDB mode. When the debugger
> > detaches, it also continues execution. This speeds up debugging,
> > especiall
Nate Lawson writes:
> I've put together a patch that enables a kernel on the target machine to
> detect a GDB packet and automatically enter GDB mode. When the debugger
> detaches, it also continues execution. This speeds up debugging,
> especially when the target is in a remote location. The pa
On Mon, Jul 08, 2002 at 08:37:37PM -0500, Erik Greenwald wrote:
>
> This may be a stupid question, but is gdbreplay currently broken? I just
> cvsup'd today (2002-07-08, 18:42 CST (GMT-6))
*shrug* I can't reproduce this.
> cc -O -pipe -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/gdbrepl
Erik Greenwald <[EMAIL PROTECTED]> writes:
> This may be a stupid question, but is gdbreplay currently broken? I just
> cvsup'd today (2002-07-08, 18:42 CST (GMT-6))
Yes (unless I missed the fix). Just use NO_WERROR=true for now.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL
At 10:54 AM -0700 5/27/02, David O'Brien wrote:
>Verify that your entire kernel is built with "-g -gstabs+". If you still
>cannot use gdb on a core dump, maybe there is a core dump format change
>GDB needs to catch up with. Please use the various objdump, etc. tools
>to verify what type of debug
On Mon, May 27, 2002 at 04:08:44PM +0900, Jun Kuriyama wrote:
> At Mon, 27 May 2002 02:46:01 + (UTC),
> David O'Brien wrote:
> > Add it to COPTFLAGS. Why are you adding it to DEBUG?
> > ``grep DEBUG /sys/conf/*.mk /sys/conf/Makefile.*'' shows DEBUG is not
> > used this way.
>
> I added it to
At Mon, 27 May 2002 02:46:01 + (UTC),
David O'Brien wrote:
> Add it to COPTFLAGS. Why are you adding it to DEBUG?
> ``grep DEBUG /sys/conf/*.mk /sys/conf/Makefile.*'' shows DEBUG is not
> used this way.
I added it to DEBUG because I think "-gstabs+" will be used as
replacement of "-g". I ad
On Mon, May 27, 2002 at 11:12:47AM +0900, Jun Kuriyama wrote:
> At Wed, 22 May 2002 18:54:02 + (UTC),
> David O'Brien wrote:
> > -ggdb means to use the most "expressive" debugging format the compiler
> > knows about. You want -gstabs+ or -gstabs
>
> I cannot debug a kernel with -gstabs+ opti
At Sun, 26 May 2002 21:35:28 -0500,
David W. Chapman Jr. <[EMAIL PROTECTED]> wrote:
> > % sudo gdb52
> Last time I checked, gdb was broken in -current and people were
> encouraged to use gdb in the ports system, but this may be oudated.
Yes, I'm using gdb52 from ports/devel/gdb52.
--
Jun Kur
On Mon, May 27, 2002 at 11:12:47AM +0900, Jun Kuriyama wrote:
> At Wed, 22 May 2002 18:54:02 + (UTC),
> David O'Brien wrote:
> > -ggdb means to use the most "expressive" debugging format the compiler
> > knows about. You want -gstabs+ or -gstabs
>
> I cannot debug a kernel with -gstabs+ opti
At Wed, 22 May 2002 18:54:02 + (UTC),
David O'Brien wrote:
> -ggdb means to use the most "expressive" debugging format the compiler
> knows about. You want -gstabs+ or -gstabs
I cannot debug a kernel with -gstabs+ option. Any hints about this?
% cd sys/i386/compile/WATERBLUE
% grep gdb ../
On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote:
> On Monday 20 May 2002 3:49 am, Terry Lambert wrote:
> > Steve Kargl wrote:
> > > > Use "-ggdb" instead, thus avoiding DWARF.
> > >
> > > BZZZT... Thanks for play!
-ggdb means to use the most "expressive" debugging format the compiler
On Wednesday 22 May 2002 6:49 pm, David O'Brien wrote:
> On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote:
> > GDB 5.2 works pretty well with -current - I've been using it recently. I
> > plan to upgrade GDB in -current to 5.2 soon (as soon as David has enough
> > time to sort out the C
On Wed, May 22, 2002 at 09:57:24AM +0100, Doug Rabson wrote:
> GDB 5.2 works pretty well with -current - I've been using it recently. I plan
> to upgrade GDB in -current to 5.2 soon (as soon as David has enough time to
> sort out the CVS magic).
I fail to see your patches to gdb 5.2 for the ker
On Monday 20 May 2002 3:49 am, Terry Lambert wrote:
> Steve Kargl wrote:
> > > Use "-ggdb" instead, thus avoiding DWARF.
> >
> > BZZZT... Thanks for play!
>
> Did Mark Peek's suggestion of using the gdb that matched
> the compiler (gdb 5.2 from ports) work instead?
GDB 5.2 works pretty well with
Steve Kargl wrote:
> > Use "-ggdb" instead, thus avoiding DWARF.
>
> BZZZT... Thanks for play!
Did Mark Peek's suggestion of using the gdb that matched
the compiler (gdb 5.2 from ports) work instead?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in
On Sun, May 19, 2002 at 05:50:32PM -0700, Terry Lambert wrote:
>
> > Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.
>
> Use "-ggdb" instead, thus avoiding DWARF.
>
BZZZT... Thanks for play!
kargl[204] gcc -ggdb a.c
kargl[205] gdb a.out
GNU gdb 4.18
Copyright 1998 Free Software Foun
Steve Kargl wrote:
> Finally, since you're quick with the wit, can you tell me
> how to debug the following problem when I can't compile
> the debugger.
[ ... ]
> gcc -g a.c
[ ... ]
> Dwarf Error: Cannot handle DW_FORM_strp in DWARF reader.
Use "-ggdb" instead, thus avoiding DWARF.
-- Terry
On 2002-05-19 17:00, Matthew Dillon wrote:
>
> :> You know, every time I update my -current sources it's winding up
> :> taking me an entire day to get things to build again.
> :
> :There are cases where updating with the `new files' requires that you
> :have updated to the `new files', a
:> You know, every time I update my -current sources it's winding up
:> taking me an entire day to get things to build again.
:
:There are cases where updating with the `new files' requires that you
:have updated to the `new files', aka chicken and egg problems. This
:is true with the -D
On 2002-05-19 13:31, Matthew Dillon wrote:
> David O'Brien wrote:
>:
>:Because we are wanting for people to let the dust settle on the switch to
>:GCC 3.1. It is best for people to juse use -DNO_WERROR for now.
>:Patience.
>
> Ahhh.. so *that's* why everything broke when I did a full update.
At 2:58 PM -0700 5/19/02, Steve Kargl wrote:
>Finally, since you're quick with the wit, can you tell me
>how to debug the following problem when I can't compile
>the debugger.
>
>kargl[223] cat a.c
>#include
>int main(void) {
>/* This isn't the problem. The problem is with gdb. */
>abort
On Sun, May 19, 2002 at 02:19:27PM -0700, Terry Lambert wrote:
> Both Twins: "Wonder Twin powers, Activate!"
>
> Jayna:"Take the form of ... patches!"
> Zan: "Take the form of ... a complaining email!"
> Gleek the code monkey:"Gleek! Gleek! Gleek!"
>
Terr
David O'Brien wrote:
> > > Warnings are treated as errors. Since GCC 3.1 has brought a hell of a
> > > lot more warnings with us, you should use -DNO_WERROR until the dust
> > > of the GCC 3.1 import settles down.
> >
> > If everyone is using -DNO_WERROR, then who would report build
> > problems
:> > lot more warnings with us, you should use -DNO_WERROR until the dust
:> > of the GCC 3.1 import settles down.
:>
:> If everyone is using -DNO_WERROR, then who would report build
:> problems :-).
:
:Because we are wanting for people to let the dust settle on the switch to
:GCC 3.1. It is be
On Sat, May 18, 2002 at 08:12:15PM -0700, Steve Kargl wrote:
> > Warnings are treated as errors. Since GCC 3.1 has brought a hell of a
> > lot more warnings with us, you should use -DNO_WERROR until the dust
> > of the GCC 3.1 import settles down.
>
> If everyone is using -DNO_WERROR, then who
On 2002-05-18 20:12, Steve Kargl wrote:
> On Sun, May 19, 2002 at 05:31:08AM +0300, Giorgos Keramidas wrote:
> > Warnings are treated as errors. Since GCC 3.1 has brought a hell
> > of a lot more warnings with us, you should use -DNO_WERROR until
> > the dust of the GCC 3.1 import settles down.
>
On Sun, May 19, 2002 at 05:31:08AM +0300, Giorgos Keramidas wrote:
> On 2002-05-18 12:56, Steve Kargl wrote:
> > ===> gnu/usr.bin/binutils/gdb
> > cc -O -pipe -march=athlon -D_GNU_SOURCE -I.
>-I/usr/src/gnu/usr.bin/binutils/gdb/i386 -I/usr/src/gnu/usr.bin/binutils/gdb
>-I/usr/src/gnu/usr.bin/bin
On 2002-05-18 12:56, Steve Kargl wrote:
> ===> gnu/usr.bin/binutils/gdb
> cc -O -pipe -march=athlon -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/gdb/i386
>-I/usr/src/gnu/usr.bin/binutils/gdb
>-I/usr/src/gnu/usr.bin/binutils/gdb/../libbfd/i386
>-I/usr/src/gnu/usr.bin/binutils/gdb/../../../.
On Sun, 20 Jan 2002 17:18:30 PST, k Macy wrote:
> Who is the current GDB maintainer?
Not sure there's a single maintainer, but I know these two gentlemen
take a keen interest in the beast:
Bruce Evans <[EMAIL PROTECTED]>
Brian Dean <[EMAIL PROTECTED]>
Ciao,
Sheldon.
To Unsubscribe: send mai
At 9:22 AM +0200 9/18/01, Mark Santcroos wrote:
>Hi Peter,
>
>What is the state of this (for i386)?
>
>Mark
>
>On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote:
>> Marcel Moolenaar wrote:
>> >
>> > Gang,
>> >
>> > I don't know exactly what the gdb(1) problems on Alpha are, but
Hi Peter,
What is the state of this (for i386)?
Mark
On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote:
> Marcel Moolenaar wrote:
> >
> > Gang,
> >
> > I don't know exactly what the gdb(1) problems on Alpha are, but we
> > do have a problem that's probably not specific to an arc
On Sun, Sep 16, 2001 at 11:24:54AM -0700, Julian Elischer wrote:
>
> peter has been working on this...
>
> It's because the process structure and u-area have changed entirely.
Hmmm... I can't explain the behaviour I see with this info. Can you
explain why gdb(1) gets the SIGTRAP?
--
Marcel M
Marcel Moolenaar wrote:
>
> Gang,
>
> I don't know exactly what the gdb(1) problems on Alpha are, but we
> do have a problem that's probably not specific to an architecture.
>
> The problem is basicly this: one cannot debug any programs because
> gdb(1) gets a SIGTRAP delivered when it invokes
hi, there!
On Fri, 25 Aug 2000, John DeBoskey wrote:
>There appears to be a problem with gdb when debugging
> dynamically loaded images. On 5.0-current with
> sources current and built as of this evenning and a
> 4.1-STABLE system, the following incorrect result is seen:
PR/20373
Solution:
On Sun, 2 Apr 2000, Mirko Viviani wrote:
> Ciao.
>
> As stated in gdb mlist, gdb 5.0 is on the way but it hasn't support for
> freebsd-elf in
> the package. Is there anyone that could explain me why ?
You're more likely to get an answer by asking the gdb developers on the
gdb "mlist" :-)
Kri
Pascal Hofstee <[EMAIL PROTECTED]> writes:
> just noticed this again. And considering 4.0 is coming up soon, I really
> Compiling this program with -ggdb will give normal results (a list of i =
> 0, upto i = 9). However when running the program through gdb Every Value
> you can print is completely
On Mon, 22 Nov 1999, Sheldon Hearn wrote:
>
> On Sat, 20 Nov 1999 20:24:47 EST, Wes Morgan wrote:
>
> > (gdb) r
> > Starting program: /usr/home/by-tor/mms-0.90/./mms
> > warning: find_solib: Can't read pathname for load map: Bad address
> >
> > Segmentation fault (core dumped)
>
> You're not a
On Sat, 20 Nov 1999 20:24:47 EST, Wes Morgan wrote:
> (gdb) r
> Starting program: /usr/home/by-tor/mms-0.90/./mms
> warning: find_solib: Can't read pathname for load map: Bad address
>
> Segmentation fault (core dumped)
You're not alone. The work-around is to compile with --static.
Ciao,
Sh
I tried doing the same on FreeBSD 3.2-STABLE
but when I run it it complains that it is unable to find dynamic linker
breakpoint function and then it stops with a SIGTRAP.
Any ideas what might be wrong?
Thanks.
-Kip
On Fri, 20 Aug 1999, Richard Cownie wrote:
> I
on 3.2-R gdb-4.18 will core dump without fail when I try to read a core
file generated by the C++ program I am developing - gdb-4.17 does not have
this problem.
-Kip
On Tue, 31 Aug 1999, Alex Zepeda wrote:
> On Sun, 22 Aug 1999, Richard Cownie wrote:
>
>
On Sun, 22 Aug 1999, Richard Cownie wrote:
> On Sat, 21 Aug 1999, David O'Brien wrote:
> > Are you saying 4.17 is better than 4.18 for debugging C++? Or are you
> > saying you didn't know FreeBSD comes with gdb:
>
> gdb-4.18 is badly broken on all platforms (at least for C++). You can't
> call
Richard Cownie wrote:
>
> I managed to build gdb-4.17 in FreeBSD 4.0, here's how to do it:
>
> 1) gdb-4.17/configure --host=i386-unknown-freebsdelf4.0
> Have to specify the host explicitly, otherwise it doesn't realize
> it needs to use ELF.
>
> 2) in gdb-4.17/Makefile, add "-DSVR4_SHAR
On Sunday, 29 August 1999 at 10:46:33 +0200, Pascal Hofstee wrote:
> On Sun, 29 Aug 1999, Greg Lehey wrote:
>
>>> I seem to having some weird problems using GDB on 4.0-CURRENT
>>> 27for (j = 1; j <= 31; j++) {
>>> (gdb)
>>> 28 temp = wmalloc(sizeof(ADay));
>>> (gdb) print
On Sun, 29 Aug 1999, Greg Lehey wrote:
> > I seem to having some weird problems using GDB on 4.0-CURRENT
> > 27for (j = 1; j <= 31; j++) {
> > (gdb)
> > 28 temp = wmalloc(sizeof(ADay));
> > (gdb) print j
> > $1 = -1077947156
> Does it do this without the -O flag? It ma
On Sunday, 29 August 1999 at 10:37:32 +0200, Pascal Hofstee wrote:
>
> I seem to having some weird problems using GDB on 4.0-CURRENT
>
> I am getting things like the following:
>
> 27for (j = 1; j <= 31; j++) {
> (gdb)
> 28 temp = wmalloc(sizeof(ADay));
> (gdb) print j
>
In <[EMAIL PROTECTED]>, Daniel Eischen wrote:
> > Did anyone of you took care that you can build an aout gdb on an ELF
> > FreeBSD system?
> >
> > I don't mean a gdb that is aout, but one that can debug aout binaries.
>
> I thought the gdb in our base system could debug aout binaries. Or
> am
> Did anyone of you took care that you can build an aout gdb on an ELF
> FreeBSD system?
>
> I don't mean a gdb that is aout, but one that can debug aout binaries.
I thought the gdb in our base system could debug aout binaries. Or
am I sadly mistaken.
> That would be most useful to have as a p
In <[EMAIL PROTECTED]>, Daniel Eischen wrote:
> Richard Cownie wrote:
> > On Sat, 21 Aug 1999, David O'Brien wrote:
> > > Are you saying 4.17 is better than 4.18 for debugging C++? Or are you
> > > saying you didn't know FreeBSD comes with gdb:
> >
> > gdb-4.18 is badly broken on all platforms (
> (gdb) run
> Starting program: /tmp/./sieve
> Program received signal SIGBUS, Bus error.
That reminds me. I thought that SIGBUS meant byte-alignment errors.
What does it mean on FreeBSD/x86?
Cheers,
joelh
--
Joel Ray Holveck - [EMAIL PROTECTED]
Fourth law of programming:
Anything that
Richard Cownie wrote:
> On Sat, 21 Aug 1999, David O'Brien wrote:
> > Are you saying 4.17 is better than 4.18 for debugging C++? Or are you
> > saying you didn't know FreeBSD comes with gdb:
>
> gdb-4.18 is badly broken on all platforms (at least for C++). You can't
> call methods from the gdb c
On Sat, 21 Aug 1999, David O'Brien wrote:
> Are you saying 4.17 is better than 4.18 for debugging C++? Or are you
> saying you didn't know FreeBSD comes with gdb:
gdb-4.18 is badly broken on all platforms (at least for C++). You can't
call methods from the gdb command line, and also it frequent
> I managed to build gdb-4.17 in FreeBSD 4.0, here's how to do it:
...
> Then it should all build (and perhaps work). The same hacks probably apply
> to gdb-4.18 and gdb-current (but so far gdb-4.17 is the most useful version
> I've seen for debugging C++).
Are you saying 4.17 is better than 4.1
In article <[EMAIL PROTECTED]>,
Amancio Hasty <[EMAIL PROTECTED]> wrote:
> > On 18 Aug 1999, Joel Ray Holveck wrote:
> >
> > > That reminds me. I thought that SIGBUS meant byte-alignment errors.
> > > What does it mean on FreeBSD/x86?
>
> The boehm garbage collector is trying to find the memo
> On 18 Aug 1999, Joel Ray Holveck wrote:
>
> > > (gdb) run
> > > Starting program: /tmp/./sieve
> > > Program received signal SIGBUS, Bus error.
> >
> > That reminds me. I thought that SIGBUS meant byte-alignment errors.
> > What does it mean on FreeBSD/x86?
>
> Another possible source for S
On 18 Aug 1999, Joel Ray Holveck wrote:
> > (gdb) run
> > Starting program: /tmp/./sieve
> > Program received signal SIGBUS, Bus error.
>
> That reminds me. I thought that SIGBUS meant byte-alignment errors.
> What does it mean on FreeBSD/x86?
Another possible source for SIGBUS should be gene
> (gdb) run
> Starting program: /tmp/./sieve
> Program received signal SIGBUS, Bus error.
That reminds me. I thought that SIGBUS meant byte-alignment errors.
What does it mean on FreeBSD/x86?
Cheers,
joelh
--
Joel Ray Holveck - [EMAIL PROTECTED]
Fourth law of programming:
Anything that
A side note on gdb-4.18 8)
(gdb) run
Starting program: /tmp/./sieve
Program received signal SIGBUS, Bus error.
0x281eeac7 in GC_find_limit (p=0xbfbfcff8 "", up=1)
at ../../../../libgcj-2.95/boehm-gc/os_dep.c:681
681 ../../../../libgcj-2.95/boehm-gc/os_dep.c: No such file or directory.
On Tue, 17 Aug 1999, Alex Zepeda wrote:
> 4.17 is really no better, it tended to crash on some C++ programs. If
> 4.18 doesn't work, try sending email to the authors of gdb, or look for a
> pre-release version.
>
> - alex
>From personal experience here, I disagree. We use gdb-4.17 all the
time
On Tue, 17 Aug 1999, Richard Cownie wrote:
> I have a problem with gdb in 4.0-CURRENT. gdb-4.18 is almost
> completely useless for debugging C++ - oveload resolution is
> completely broken, and attempting to call functions frequently causes
> it to hang. I believe this is true on linux and sola
On Fri, Jun 25, 1999 at 11:35:04PM -0700, Alex Zepeda wrote:
> I've tried numerous times (updating the kernel, buildworld, etc) to get
> gdb to work, but so far it seems like ELF coredumps are broken (course
> this could be a C++ issue too):
It was fixed several weeks ago, at least in 4.0.
--
This has been happening to me, as well!
gdb takes a sig 11 and dies on coredumps on my -current as well. Can't even
get to a (gdb) prompt!
Also, gcore is busted!
Barfs on a line from /proc/${PID}/map
It appears that the format of /map lines has changed, and the scanf is
failing...
- Origina
79 matches
Mail list logo
