[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS 1.11.18 - Windows Bug - cannot write to stdout
From: |
Mark D. Baushke |
Subject: |
Re: CVS 1.11.18 - Windows Bug - cannot write to stdout |
Date: |
Thu, 18 Nov 2004 08:10:08 -0800 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Derek Robert Price <derek@ximbiot.com> writes:
> Mark D. Baushke wrote:
>
> > d) cvs 1.11.18 under MacOS X (10.3.6) sometimes generates a bus error
> > during a call to tzset().
> >
> > My opinion is that 10.3.6 is just buggy and that users could work
> > around the problem changing config.h to use #undef HAVE_TZSET, but
> > I have not had opportunity to investigate any further.
> > (Report from "Marius Schamschula" <marius173@mchsi.com>.)
>
>
> Sometimes? Like in certain timezones or unpredictably? Anyhow, if
> #undef HAVE_TZSET works, then I will agree with you, at least until a
> better solution makes itself apparent.
Unpredictably. See attached e-mail on the subject.
-- Mark
--------------- archive message ---------------
From: Marius Schamschula <marius173@mchsi.com>
Subject: Re: Test failure of cvs 1.11.18 on Mac OS X 10.3.6 a.k.a. Darwin 7.6
Date: Mon, 15 Nov 2004 19:26:20 -0600
To: "Mark D. Baushke" <mdb@cvshome.org>
Mark,
First of all. Thanks for the quick intro to getting at the core dump
data.
I always like entries to the journal of sometimes reproducible
results...
Well, sort of. Here is what happened when I ran the test by itself:
titan:/tmp/cvs-1.11.18/src marius$ sh ./sanity.sh `pwd`/cvs multibranch2
This test should produce no other output than this message, and a
final "OK".
(Note that the test can take an hour or more to run and periodically
stops
for as long as one minute. Do not assume there is a problem just
because
nothing seems to happen for a long time. If you cannot live without
running status, try the command: `tail -f check.log' from another
window.)
OK, all 17 tests passed (18 tests passed with warnings).
However, when I re-ran make check the bus error was reproduced (for a
third time).
titan:/tmp/cvs-1.11.18 marius$ gdb /tmp/cvs-1.11.18/src/cvs
/cores/core.24891
GNU gdb 5.3-20030128 (Apple version gdb-309) (Thu Dec 4 15:41:30 GMT
2003)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "powerpc-apple-darwin".
Reading symbols for shared libraries .. done
Core was generated by `/tmp/cvs-1.11.18/src/cvs'.
#0 0x9000ed64 in tzset_basic ()
(gdb) bt
#0 0x9000ed64 in tzset_basic ()
#1 0x9001d87c in tzset ()
#2 0x9001d87c in tzset ()
#3 0x0002aaa8 in main (argc=5, argv=0xbffffba4) at main.c:424
(gdb) dir /tmp/cvs-1.11.18/src
Source directories searched: /tmp/cvs-1.11.18/src:$cdir:$cwd
(gdb) up
#1 0x9001d87c in tzset ()
(gdb) list
383 int
384 main (argc, argv)
385 int argc;
386 char **argv;
387 {
388 cvsroot_t *CVSroot_parsed = NULL;
389 int cvsroot_update_env = 1;
390 char *cp, *end;
391 const struct cmd *cm;
392 int c, err = 0;
(gdb) info registers
r0 0x0 0
r1 0xbffff980 3221223808
r2 0x0 0
r3 0x801d4c 8396108
r4 0x90104a44 2416986692
r5 0x0 0
r6 0xfefefeff 4278124287
r7 0x80808080 2155905152
r8 0x0 0
r9 0x801d50 8396112
r10 0x464c52ff 1179407103
r11 0xa0003c50 2684370000
r12 0x80808080 2155905152
r13 0x0 0
r14 0x0 0
r15 0x0 0
r16 0x0 0
r17 0x0 0
r18 0x0 0
r19 0x0 0
r20 0x0 0
r21 0x0 0
r22 0x0 0
r23 0x0 0
r24 0x0 0
r25 0x0 0
r26 0xbffffba0 3221224352
r27 0xa000ec48 2684415048
r28 0xa000ec48 2684415048
r29 0xbfffff6b 3221225323
r30 0x0 0
r31 0x9000ec48 2415979592
pc 0x9000ed08 2415979784
ps 0xd030 53296
cr 0x22000042 570425410
lr 0x9000ed08 2415979784
ctr 0x90007620 2415949344
xer 0x20000000 536870912
mq 0x0 0
fpscr 0x0 0
vscr 0x0 0
vrsave 0x0 0
I hope this helps.
On Nov 15, 2004, at 10:44 AM, Mark D. Baushke wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Marius Schamschula <marius173@mchsi.com> writes:
>
>> Mark,
>>
>> Thanks for getting back to me.
>>
>> On Nov 15, 2004, at 1:37 AM, Mark D. Baushke wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Marius Schamschula <marius173@mchsi.com> writes:
>>>
>>>> I built cvs 1.11.18 under Mac OS X 10.3.6. However, when running
>>>> make
>>>> check I get a failure:
>>>>
>>>> ./sanity.sh: line 1: 17170 Bus error
>>>> /tmp/cvs-1.11.18/src/cvs -q co -l .
>>>> exit status was 138
>>>> FAIL: multibranch2-1
>>>>
>>>> I had no such issue under cvs 1.11.17.
>>>
>>> I do not have access to a 10.3.6 system, but cvs 1.11.18 passed
>>> multibranch with no problems my Mac OS X 10.2.8 Darwing Kernel
>>> Version
>>> 6.8 PowerBookG4 system.
>>
>> I didn't have this problem on my Mac OS X 10.2.8 build system either.
>
> Hmmm... okay.
>
>>> Would you please provide more details as to where the bus error
>>> occured?
>>> A traceback of the core file would be an excellent start.
>>
>> May I ask how this is done? Most references i find for traceback are
>> for python. I couldn't find any cores.
>
> First, set things up to generate a core dump on a bus error
>
> The command:
>
> ulimit -c
>
> will print out the size of cores that the system
> allows you to dump. The default is probably '0'
> which means that core files will not be generated.
>
> The command:
>
> ulimit -c unlimited
>
> specifies that a core dump file of any size is
> allowed for children of this shell. So, set that
> if it is not already unlimited.
>
> Next, run just the test that is failing:
>
> cd /tmp/cvs-1.11.18/src
> sh ./sanity.sh `pwd`/cvs multibranch2
>
> if it fails, it should leave a core file in
> /tmp/cvs-sanity someplace. Use a command like
>
> 'ls -R /tmp/cvs-sanity'
> or
> 'find /tmp/cvs-sanity -name \*core\*'
>
> to locate it.
>
> Next, run gdb (this assumes that 'gdb' is the
> debugger you have installed on your system) on the
> core file.
>
> cd /tmp/cvs-sanity/1
> gdb /tmp/cvs-1.11.18/src/cvs <name-of-core-file>
>
> The next few commands are issued at the gdb prompt:
>
> (gdb) bt
> (gdb) dir /tmp/cvs-1.11.18/src
> (gdb) up
>
> Commands like
>
> backtrace (print backtrace of all stack frames)
> list (list the source for the line)
> print EXP (print the value of the expression EXP)
> up (to move up a stack frame)
> help (getting command help)
> help stack
> info stack
> info registers
>
> will help you navigate around. It would be good to
> know the values of the variables that were
> involved in the core dump happening as a part of
> your response.
>
> Please send your information to the bug-cvs@gnu.org list.
>
> Good luck,
> -- Mark
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.3 (FreeBSD)
>
> iD8DBQFBmNz03x41pRYZE/gRAonQAKC8bXGa/NMw0X6d29Zusgc7SCC2QwCghvo8
> fwPTyvzDfP9Eg36/kodks0Y=
> =z8Oz
> -----END PGP SIGNATURE-----
>
>
Marius
- --
Marius Schamschula Webmaster
The Huntsville Macintosh Users Group
www.hmug.org
webmaster at hmug dot org marius at schamschula dot com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFBnMlgDsmuPPFOO2cRAmkjAJ9CYy1/m06hRr3gSJB+r5/5wIMC9ACdHqpC
lfmwByIJCkHWoqXbZX28vw0=
=huSR
-----END PGP SIGNATURE-----
- CVS 1.11.18 - Windows Bug - cannot write to stdout, Conrad T. Pino, 2004/11/17
- Re: CVS 1.11.18 - Windows Bug - cannot write to stdout, Mark D. Baushke, 2004/11/17
- RE: CVS 1.11.18 - Windows Bug - cannot write to stdout, Conrad T. Pino, 2004/11/17
- Re: CVS 1.11.18 - Windows Bug - cannot write to stdout, Mark D. Baushke, 2004/11/17
- Re: CVS 1.11.18 - Windows Bug - cannot write to stdout, Derek Robert Price, 2004/11/18
- Re: CVS 1.11.18 - Windows Bug - cannot write to stdout,
Mark D. Baushke <=
- RE: CVS 1.11.18 - Windows Bug - cannot write to stdout, Conrad T. Pino, 2004/11/18
- Re: CVS 1.11.18 - Windows Bug - cannot write to stdout, Derek Robert Price, 2004/11/18
- RE: CVS 1.11.18 - Windows Bug - cannot write to stout, Conrad T. Pino, 2004/11/20
- Re: CVS 1.11.18 - Windows Bug - cannot write to stout, Derek Robert Price, 2004/11/20