Menu
▾
▴
bashdb-devel
|
From: Eric B. <eb...@by...> - 2007-04-19 13:09:30
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was trying to upgrade the cygwin installation of bashdb to the latest release, and encountered 2 test failures atop bash-3.2.15. I'm not familiar enough with the bashdb sources to know where to look for the cause of these two failures, but since they all mention dbg-cmds.inc line 944, I wonder if there is a bug there. Any ideas? checking brkpt1... checking brkpt2... - --- /home/eblake/bashdb-3.1_0.08-1/build/test/brkpt2.check 2007-04-19 06:42:53.453125000 -0600 +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/brkpt2.right 2007-01-19 20:43:30.000000000 -0700 @@ -195,19 +195,13 @@ 11: local -i j=i+1 + ### another x command... + x j - -../dbg-cmds.inc: line 944: ((: declare -i j="1" - -1 : syntax error in expression (error token is "j="1" - -1 ") - -1 +declare -i j="1" + ### another x command (+5 than value above) ... + x j+5 6 + ### x command of string y + x y - -../dbg-cmds.inc: line 944: ((: declare -- y="b" - -1 : syntax error in expression (error token is "y="b" - -1 ") - -y +declare -- y="b" + ### x of a function ... + x fn2 fn2 () FAIL: run-brkpt - --- /home/eblake/bashdb-3.1_0.08-1/build/test/command.check 2007-04-19 06:44:10.843750000 -0600 +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/command.right 2006-12-03 15:30:52.000000000 -0700 @@ -20,10 +20,7 @@ + continue Breakpoint 1 hit (1 times). + x x - -../dbg-cmds.inc: line 944: ((: declare -- x="22" - -1 : syntax error in expression (error token is "x="22" - -1 ") - -22 +declare -- x="22" (dbg-test1.sh:23): 23: y=23 + # FAIL: run-command - -- Don't work too hard, make some time for fun as well! Eric Blake eb...@by... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGJ2ow84KuGfSFAYARAok2AJ9jZn/f4/EDZHXQBOaQyIhgSqLS2wCgqV4O Vw3+oI0N6WeoE9jQps34V4Y= =Fl9N -----END PGP SIGNATURE----- |
|
From: Rocky B. <roc...@gm...> - 2007-04-20 01:56:15
Attachments:
bashdb.patch
shell.out
|
I spent a little time looking at this after a very long day at work. Alas
I'm too tired to investigate further so I'll just report what I know at
present.
In short, as best as I can tell I think this is a bug in bash. Details are
below, but if things were working before and with the latest round of
patches things got broken, it would indicate that either bash introduced a
bug or there is something invalid that bashdb is doing that causes bash to
behave badly. Although I tried this on cygwin, but it would be interesting
to try to compile on a different platform to see if similar failures occur.
Some details follow. At the line mentioned, line 944 of dbg-cmd.inc, I
turned on set -x tracing. Basically I added this:
export PS4='(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]}\n'
set -x
and a matching set +x later on. The attached patch might be of help here.
To run just the failing program one can go into the test directory and run
"./brkpt2.tests"
Here is what I see near the failure:
...
+ ### another x command...
+ x j
(((((../dbg-cmds.inc:946): _Dbg_do_x
_Dbg_is_var j
(((((../dbg-fns.inc:126): _Dbg_is_var
declare -p j
(((((../dbg-fns.inc:127): _Dbg_is_var
[[ 0 != 0 ]]
(((((../dbg-fns.inc:130): _Dbg_is_var
echo 1
((((../dbg-cmds.inc:946): _Dbg_do_x
(( declare -i j="1"
1 ))
../dbg-cmds.inc: line 946: declare -i j="1"
1 : syntax error in expression (error token is "j="1"
1 ")
What's wrong here is that line 946 is not "(( declare -i j="1" .... but
if (( `_Dbg_is_var $_Dbg_expr` )) ; then
So what seems to be happening is that the wrong text is getting substituted
back inside the backtick. What you should have seen was (( 1 )) because
there was that "echo 1". Interestingly whenever _Dbg_is_var decides to run
"echo 0" instead of "echo 1", that does get substituted back correctly.
I'll attach a log of my run. Finally, I don't know if this is related, but I
seem to be getting "out of resource" errors after running the tests.
5 [main] sh 64760 fork: child -1 - CreateProcessA failed, errno 11
../dbg-pre.inc: fork: Resource temporarily unavailable
5 [main] sh 64676 fork: child -1 - CreateProcessA failed, errno 11
With Windows ,one never knows what's going on.
On 4/19/07, Eric Blake <eb...@by...> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I was trying to upgrade the cygwin installation of bashdb to the latest
> release, and encountered 2 test failures atop bash-3.2.15. I'm not
> familiar enough with the bashdb sources to know where to look for the
> cause of these two failures, but since they all mention dbg-cmds.inc line
> 944, I wonder if there is a bug there. Any ideas?
>
> checking brkpt1...
> checking brkpt2...
> - --- /home/eblake/bashdb-3.1_0.08-1/build/test/brkpt2.check 2007-04-19
> 06:42:53.453125000 -0600
> +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/brkpt2.right
> 2007-01-19 20:43:30.000000000 -0700
> @@ -195,19 +195,13 @@
> 11: local -i j=i+1
> + ### another x command...
> + x j
> - -../dbg-cmds.inc: line 944: ((: declare -i j="1"
> - -1 : syntax error in expression (error token is "j="1"
> - -1 ")
> - -1
> +declare -i j="1"
> + ### another x command (+5 than value above) ...
> + x j+5
> 6
> + ### x command of string y
> + x y
> - -../dbg-cmds.inc: line 944: ((: declare -- y="b"
> - -1 : syntax error in expression (error token is "y="b"
> - -1 ")
> - -y
> +declare -- y="b"
> + ### x of a function ...
> + x fn2
> fn2 ()
> FAIL: run-brkpt
>
> - --- /home/eblake/bashdb-3.1_0.08-1/build/test/command.check 2007-04-19
> 06:44:10.843750000 -0600
> +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/command.right
> 2006-12-03 15:30:52.000000000 -0700
> @@ -20,10 +20,7 @@
> + continue
> Breakpoint 1 hit (1 times).
> + x x
> - -../dbg-cmds.inc: line 944: ((: declare -- x="22"
> - -1 : syntax error in expression (error token is "x="22"
> - -1 ")
> - -22
> +declare -- x="22"
> (dbg-test1.sh:23):
> 23: y=23
> + #
> FAIL: run-command
>
> - --
> Don't work too hard, make some time for fun as well!
>
> Eric Blake eb...@by...
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
> Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGJ2ow84KuGfSFAYARAok2AJ9jZn/f4/EDZHXQBOaQyIhgSqLS2wCgqV4O
> Vw3+oI0N6WeoE9jQps34V4Y=
> =Fl9N
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bashdb-devel mailing list
> Bas...@li...
> https://lists.sourceforge.net/lists/listinfo/bashdb-devel
>
|
|
From: Rocky B. <roc...@gm...> - 2007-04-24 08:08:44
|
I've just compiled bash 3.2.15 on GNU/Linux (with gcc version 4.1.0 and -O2
optimization). I was able to run the regression tests without any errors
both on bashdb 3.1-0.08 and current CVS sources.
On cygwin where I noticed a failure, I was using the installed bash from the
Interent. Furthermore bashdb wasn't using readarray the C-compiled
extension.
Given this, right now the evidence suggests that the problem mentioned in
this thread is in the bash 3.2.15 binary on cygwin.
On 4/19/07, Rocky Bernstein <roc...@gm...> wrote:
>
> I spent a little time looking at this after a very long day at work. Alas
> I'm too tired to investigate further so I'll just report what I know at
> present.
>
> In short, as best as I can tell I think this is a bug in bash. Details are
> below, but if things were working before and with the latest round of
> patches things got broken, it would indicate that either bash introduced a
> bug or there is something invalid that bashdb is doing that causes bash to
> behave badly. Although I tried this on cygwin, but it would be interesting
> to try to compile on a different platform to see if similar failures occur.
>
> Some details follow. At the line mentioned, line 944 of dbg-cmd.inc, I
> turned on set -x tracing. Basically I added this:
> export PS4='(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]}\n'
> set -x
> and a matching set +x later on. The attached patch might be of help here.
>
> To run just the failing program one can go into the test directory and run
> "./brkpt2.tests"
>
> Here is what I see near the failure:
>
> ...
> + ### another x command...
> + x j
> (((((../dbg-cmds.inc:946): _Dbg_do_x
> _Dbg_is_var j
> (((((../dbg-fns.inc:126): _Dbg_is_var
> declare -p j
> (((((../dbg-fns.inc:127): _Dbg_is_var
> [[ 0 != 0 ]]
> (((((../dbg-fns.inc:130): _Dbg_is_var
> echo 1
> ((((../dbg-cmds.inc:946): _Dbg_do_x
> (( declare -i j="1"
> 1 ))
> ../dbg-cmds.inc: line 946: declare -i j="1"
> 1 : syntax error in expression (error token is "j="1"
> 1 ")
>
> What's wrong here is that line 946 is not " (( declare -i j="1" .... but
>
> if (( `_Dbg_is_var $_Dbg_expr` )) ; then
>
> So what seems to be happening is that the wrong text is getting
> substituted back inside the backtick. What you should have seen was (( 1 ))
> because there was that "echo 1". Interestingly whenever _Dbg_is_var decides
> to run "echo 0" instead of "echo 1", that does get substituted back
> correctly.
>
> I'll attach a log of my run. Finally, I don't know if this is related, but
> I seem to be getting "out of resource" errors after running the tests.
>
> 5 [main] sh 64760 fork: child -1 - CreateProcessA failed, errno 11
> ../dbg-pre.inc: fork: Resource temporarily unavailable
> 5 [main] sh 64676 fork: child -1 - CreateProcessA failed, errno 11
>
> With Windows ,one never knows what's going on.
>
>
>
>
> On 4/19/07, Eric Blake <eb...@by...> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I was trying to upgrade the cygwin installation of bashdb to the latest
> > release, and encountered 2 test failures atop bash-3.2.15. I'm not
> > familiar enough with the bashdb sources to know where to look for the
> > cause of these two failures, but since they all mention dbg-cmds.incline
> > 944, I wonder if there is a bug there. Any ideas?
> >
> > checking brkpt1...
> > checking brkpt2...
> > - --- /home/eblake/bashdb-3.1_0.08-1/build/test/brkpt2.check 2007-04-19
> > 06:42:53.453125000 -0600
> > +++ /home/eblake/bashdb-3.1_0.08-1/src/bashdb-3.1-0.08/test/brkpt2.right
> > 2007-01-19 20:43:30.000000000 -0700
> > @@ -195,19 +195,13 @@
> > 11: local -i j=i+1
> > + ### another x command...
> > + x j
> > - -../dbg-cmds.inc: line 944: ((: declare -i j="1"
> > - -1 : syntax error in expression (error token is "j="1"
> > - -1 ")
> > - -1
> > +declare -i j="1"
> > + ### another x command (+5 than value above) ...
> > + x j+5
> > 6
> > + ### x command of string y
> > + x y
> > - -../dbg-cmds.inc: line 944: ((: declare -- y="b"
> > - -1 : syntax error in expression (error token is "y="b"
> > - -1 ")
> > - -y
> > +declare -- y="b"
> > + ### x of a function ...
> > + x fn2
> > fn2 ()
> > FAIL: run-brkpt
> >
> > - --- /home/eblake/bashdb-3.1_0.08-1/build/test/command.check
> > 2007-04-19
> > 06:44:10.843750000 -0600
> > +++ /home/eblake/bashdb-
> > 3.1_0.08-1/src/bashdb-3.1-0.08/test/command.right
> > 2006-12-03 15:30:52.000000000 -0700
> > @@ -20,10 +20,7 @@
> > + continue
> > Breakpoint 1 hit (1 times).
> > + x x
> > - -../dbg-cmds.inc: line 944: ((: declare -- x="22"
> > - -1 : syntax error in expression (error token is "x="22"
> > - -1 ")
> > - -22
> > +declare -- x="22"
> > (dbg-test1.sh:23):
> > 23: y=23
> > + #
> > FAIL: run-command
> >
> > - --
> > Don't work too hard, make some time for fun as well!
> >
> > Eric Blake eb...@by...
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.5 (Cygwin)
> > Comment: Public key at home.comcast.net/~ericblake/eblake.gpg<http://home.comcast.net/%7Eericblake/eblake.gpg>
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFGJ2ow84KuGfSFAYARAok2AJ9jZn/f4/EDZHXQBOaQyIhgSqLS2wCgqV4O
> > Vw3+oI0N6WeoE9jQps34V4Y=
> > =Fl9N
> > -----END PGP SIGNATURE-----
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Bashdb-devel mailing list
> > Bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/bashdb-devel
> >
>
>
>
|
|
From: Eric B. <eb...@by...> - 2007-04-28 05:26:25
Attachments:
signature.asc
|
According to Rocky Bernstein on 4/24/2007 2:08 AM: > I've just compiled bash 3.2.15 on GNU/Linux (with gcc version 4.1.0 and= =20 > -O2 optimization). I was able to run the regression tests without any > errors both on bashdb 3.1-0.08 and current CVS sources. >=20 > On cygwin where I noticed a failure, I was using the installed bash fro= m > the Interent. Furthermore bashdb wasn't using readarray the C-compiled= > extension. Have you had any success getting cygwin bash to use loadable modules, suc= h as readarray? >=20 > Given this, right now the evidence suggests that the problem mentioned > in this thread is in the bash 3.2.15 binary on cygwin. Indeed it was. There are latent bugs in the bash source code, where various builtins leak output to the wrong file if stdio is not line buffered; but cygwin bash had a local patch that did just that in order t= o fix another bug where builtins incorrectly used text mode instead of binary mode to talk over pipes. I've uploaded a new version of bash for cygwin that has the problem with builtins fixed, and verified that the bashdb testsuite passes again. --=20 Don't work too hard, make some time for fun as well! Eric Blake eb...@by... |
|
From: Rocky B. <roc...@gm...> - 2007-04-28 11:48:05
|
Comments in line . On 4/28/07, Eric Blake <eb...@by...> queries and avows: > > According to Rocky Bernstein on 4/24/2007 2:08 AM: > > I've just compiled bash 3.2.15 on GNU/Linux (with gcc version 4.1.0 and > > -O2 optimization). I was able to run the regression tests without any > > errors both on bashdb 3.1-0.08 and current CVS sources. > > > > On cygwin where I noticed a failure, I was using the installed bash from > > the Interent. Furthermore bashdb wasn't using readarray the C-compiled > > extension. > > Have you had any success getting cygwin bash to use loadable modules, such > as readarray? I deliberately did not because there was a failure and I wanted to rule out the possibility of this being caused by a readarray bug. Since it failed without readarray, I fail to see how compiling readarry would fix the problem! And unlikeliness aside, I'm not sure how helpful it would have been to know that. Furthermore, my recollection is that cygwin ships bashdb with readarray compiled. It is one of the few distributions to do that - thank you very much! (In my own experience using readarray greatly speeds up initial load time. With luck and probably lots of persistence on Misatake's part, it will get back into bash proper at some point.) > > > Given this, right now the evidence suggests that the problem mentioned > > in this thread is in the bash 3.2.15 binary on cygwin. > > Indeed it was. There are latent bugs in the bash source code, where > various builtins leak output to the wrong file if stdio is not line > buffered; but cygwin bash had a local patch that did just that in order to > fix another bug where builtins incorrectly used text mode instead of > binary mode to talk over pipes. I've uploaded a new version of bash for > cygwin that has the problem with builtins fixed, and verified that the > bashdb testsuite passes again. long rant... My take is that there are a couple of lessons here. First, test suites are good. They help you find bugs and verify the correct working of a program. Second, this is not the first time the test suite for bashdb has shown a presence of a bash bug. The bash test suite, while useful, has clearly been a bit lacking. Back when I was hacking on bash to add better debugger run-time support and the timestamped history, I made a stab at improving the bash test suite so it would be more automatic by not complaining as much when there is no problem, make running tests individually easier, and use more of the standard auto* test framework. Alas those changes didn't make it back into the source. It would be wise before a bash release to try out bashdb and run its test suite. Not just because it would be a nice thing to do for bashdb (or more precisely its users), but because it constitutes a large bash program that's freely available in GPL; in that category it isone of the few that does come with regression tests! It is not clear to me that before a general bash release, there is testing done using such a large complete bash program. Small unit tests are great, especially when they are carefully crafted and religiously applied via test-driven development (which is probably not the case here). But a second independent confirmation would be nice too. Alas, I don't have the time (nor find it satisfying) to keep tabs on the bugs bash introduced between releases. Perhaps there's a kinder, more tolerant soul out there who could help the community out by undertaking such a task. -- > Don't work too hard, make some time for fun as well! I'm not that good - I have to work hard in order to get anything done. Eric Blake eb...@by... > > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X