bug-cvs
[Top][All Lists]
Advanced

[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 <address@hidden> 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" <address@hidden>.)
> 
> 
> 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 <address@hidden>
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" <address@hidden>

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 <address@hidden> 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 <address@hidden> 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 address@hidden 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-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]