You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(9) |
Oct
(15) |
Nov
(6) |
Dec
(10) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(30) |
Sep
(4) |
Oct
(2) |
Nov
(4) |
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(2) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(2) |
2006 |
Jan
(10) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
(6) |
Aug
(13) |
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
2007 |
Jan
(4) |
Feb
(11) |
Mar
(1) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(6) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(1) |
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(9) |
Sep
(1) |
Oct
(7) |
Nov
|
Dec
(4) |
2009 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(3) |
Sep
(4) |
Oct
(3) |
Nov
(1) |
Dec
(2) |
2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(6) |
2017 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(5) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <377...@qq...> - 2023-06-03 03:08:03
|
make[3]: *** [check-TESTS] 错误 1 make[3]: 离开目录“/root/bashdb-4.2-0.7/test/integration” make[2]: *** [check-am] 错误 2 make[2]: 离开目录“/root/bashdb-4.2-0.7/test/integration” make[1]: *** [check-recursive] 错误 1 make[1]: 离开目录“/root/bashdb-4.2-0.7/test” make: *** [check-recursive] 错误 1 |
From: Todd B. <be...@gm...> - 2019-04-23 21:17:42
|
I just build and ran the tests for bashdb-4.3-0.91 on a machine running Ubuntu 16.04 (bash version 4.3.48(1)-release (x86_64-pc-linux-gnu)). I had one test error: ============================================================================ Testsuite summary for bashdb 4.3-0.91 ============================================================================ # TOTAL: 42 # PASS: 39 # SKIP: 2 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See test/integration/test-suite.log Please report to bas...@li... ============================================================================ I attached the test-suite.log from the run. -Todd -- Todd Bezenek <http://www.linkedin.com/in/toddbezenek/> be...@gm... A people hire A people, B people hire C people. --Jim Gray <http://en.wikipedia.org/wiki/Jim_Gray_(computer_scientist)> |
From: Rocky B. <ro...@gn...> - 2017-11-21 20:42:02
|
Thanks for the detailed report. Whatever the bug is, it doesn't look that serious. Will see if I can reproduce the problem. On Tue, Nov 21, 2017 at 1:49 PM, Andrew <and...@gm...> wrote: > (6) andrew@andrew integration $ bash --version > GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) > > *** > > (6) andrew@andrew integration $ cat /etc/*release > DISTRIB_ID=LinuxMint > DISTRIB_RELEASE=17.3 > DISTRIB_CODENAME=rosa > DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa" > NAME="Ubuntu" > VERSION="14.04, Trusty Tahr" > ID=ubuntu > ID_LIKE=debian > PRETTY_NAME="Ubuntu 14.04 LTS" > VERSION_ID="14.04" > HOME_URL="http://www.ubuntu.com/" > SUPPORT_URL="http://help.ubuntu.com/" > BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" > > *** > > ====================================================== > bashdb 4.3-0.91: test/integration/test-suite.log > ====================================================== > > # TOTAL: 42 > # PASS: 39 > # SKIP: 2 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > SKIP: test-file-with-spaces > =========================== > > Skipping test due to autoconf problems > > FAIL: test-bug-loc > ================== > > --- /home/andrew/Downloads/bashdb-4.3-0.91/test/integration/bug- > loc.check2017-11-21 > 18:45:16.755011602 +0000 > +++ /home/andrew/Downloads/bashdb-4.3-0.91/test/data/bug-loc. > right2014-12-11 > 13:22:03.000000000 +0000 @@ -1,10 +1,10 @@ (bug-loc.sh:5): > -5:dirname=${BASH_SOURCE%/*} # equivalent to dirname($0) > +5:dirname=${BASH_SOURCE%/*} # equivalent to dirname($0) > +# Test to see that we read in files that mentioned in breakpoints > +# but we don't step into. > +step > (bug-loc.sh:6): > -6:source ${dirname}/library.sh > +6:source ${dirname}/library.sh > +step > (bug-loc.sh:7): > 7:echo 'script line 7' > > SKIP: test-file-with-spaces > =========================== > > Skipping test due to autoconf problems > > > -- > Andrew Woodward > RLU: #437175 > https://www.linuxcounter.net/cert/437175.png > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > |
From: Andrew <and...@gm...> - 2017-11-21 19:03:00
|
(6) andrew@andrew integration $ bash --version GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu) *** (6) andrew@andrew integration $ cat /etc/*release DISTRIB_ID=LinuxMint DISTRIB_RELEASE=17.3 DISTRIB_CODENAME=rosa DISTRIB_DESCRIPTION="Linux Mint 17.3 Rosa" NAME="Ubuntu" VERSION="14.04, Trusty Tahr" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 14.04 LTS" VERSION_ID="14.04" HOME_URL="http://www.ubuntu.com/" SUPPORT_URL="http://help.ubuntu.com/" BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/" *** ====================================================== bashdb 4.3-0.91: test/integration/test-suite.log ====================================================== # TOTAL: 42 # PASS: 39 # SKIP: 2 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 SKIP: test-file-with-spaces =========================== Skipping test due to autoconf problems FAIL: test-bug-loc ================== --- /home/andrew/Downloads/bashdb-4.3-0.91/test/integration/bug-loc.check2017-11-21 18:45:16.755011602 +0000 +++ /home/andrew/Downloads/bashdb-4.3-0.91/test/data/bug-loc.right2014-12-11 13:22:03.000000000 +0000 @@ -1,10 +1,10 @@ (bug-loc.sh:5): -5:dirname=${BASH_SOURCE%/*} # equivalent to dirname($0) +5:dirname=${BASH_SOURCE%/*} # equivalent to dirname($0) +# Test to see that we read in files that mentioned in breakpoints +# but we don't step into. +step (bug-loc.sh:6): -6:source ${dirname}/library.sh +6:source ${dirname}/library.sh +step (bug-loc.sh:7): 7:echo 'script line 7' SKIP: test-file-with-spaces =========================== Skipping test due to autoconf problems -- Andrew Woodward RLU: #437175 https://www.linuxcounter.net/cert/437175.png |
From: Ntentos, S. <sta...@fo...> - 2017-11-03 12:50:33
|
-- Terveisin, STAVROS NTENTOS Associate, QA Engineer - VPN Team, EMEA FORCEPOINT M: +358 469 33 2424 www.forcepoint.com Protecting the human point. |
From: Rocky B. <roc...@gm...> - 2017-08-02 01:01:24
|
With commit 6792f1ba93337ee8ce3043e42592fe6265e5944f I think I have the last of the bash 4.4 changes addressed. I tried on Ubuntu Zesty rather than CentOS 7. So after updating from git, give it a shot and let me know how it goes. If things go well, I probably have time to put out another release. On Mon, Jul 31, 2017 at 12:12 PM, Brad Dussiaume <br...@fo... > wrote: > Hello: > > Here is the file of errors I received while running 'make check'. Do I > need to do anything to get this to work? > > Brad > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > |
From: Brad D. <br...@fo...> - 2017-07-31 16:29:04
|
Hello: Here is the file of errors I received while running 'make check'. Do I need to do anything to get this to work? Brad |
From: Rocky B. <ro...@gn...> - 2017-06-19 10:34:15
|
I had a little the time to try running the tests on bash 4.4 so I can confirm the errors and get detailed information about them. None are serious, but do indicate a change in behavior between 4.3 and 4.4 in the way bash works. The most unusual change seems to be something in comparing strings so that sorted lists appear differently and are no longer sorted. Other changes seem to be in what is reported in a BASH_SOURCE when bashdb is the first argument. So tracebacks appear differently, although they have more information now. It will probably a while for me to have the time to track down all of the bugs when using bash 4.4, but in the meantime I believe what's there most will not any significant problem in using bashdb as is. On Sun, Jun 4, 2017 at 9:52 AM, Rocky Bernstein <ro...@gn...> wrote: > Uh, ok. Just send test/integration/test-suite.log I suggested before > to me. I don't think people on the devel list are interested in the > specific differences. > > I'll look at when I get a chance, but it might not be for a while. > > On Sun, Jun 4, 2017 at 9:48 AM, jean-christophe manciot < > act...@gm...> wrote: > >> I never tried to build bashdb with bash 4.3, but with earlier bashdb git >> commits (such as the latest ones in december 2016), I had fewer failed >> tests (4) vs 9 today. >> >> On Sun, Jun 4, 2017 at 3:38 PM, Rocky Bernstein <ro...@gn...> wrote: >> >> > Thanks - I'll look at this when I get a chance. Some general information >> > and then some general questions. >> > >> > The failing integration tests look are the tests that are most fragile >> and >> > can change with bash release. Generally it's nothing serious, in that >> it is >> > the test that is wrong, not the functioning of bashdb. >> > >> > To verify this belief, look at the file test/integration/test-suite.log >> > as the above output suggests. You should see diff-style output showing >> what >> > was expected and what you got instead. Send it to me directly and I'll >> look. >> > >> > Just today earlier I was working on detecting the terminal background >> and >> > whether it was dark or light, and I recall a lot of failures in the same >> > files listed above. Most of what I had to do was make sure to pass the - >> > -no-highlight option in the tests to make output checking more >> > predictable. The kinds if differences I was seeing was in adding ansi >> > escape sequences for marking the output that I was getting but wasn't >> > expected. >> > >> > Are you working off of sourceforge git or the last release? If git, make >> > sure to "git pull" since this changed a little while ago. >> > >> > The other place where tests start failing is on a new release (from >> > bashdb's standpoint) of bash. I am not sure I have tried version 4.4 >> yet. >> > (I might have but I don't remember) >> > Is this the first time you've tried bashdb with bash version 4.4? With >> > bash 4.3 that works, right? >> > >> > >> > >> > >> > On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot < >> > act...@gm...> wrote: >> > >> >> distribution: Ubuntu Zesty >> >> bash sources: https://packages.debian.org/source/stretch/bash >> >> bash version: 4.4.12(1) (built from latest debian 4.4-5) >> >> bashdb sources: git://git.code.sf.net/p/bashdb/code >> >> bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016 >> >> bashdb configure options: >> >> --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \ >> >> --build=x86_64-pc-linux-gnu >> \ >> >> --prefix=/usr >> --sysconfdir=/etc >> >> --localstatedir=/var \ >> >> --infodir=/usr/share/info >> >> --mandir=/usr/share/man >> >> bashdb build tool: remake --trace >> >> bashdb check tool: make check >> >> bashdb tests log: attached test/integration/test-suite.log >> >> >> >> PASS: test-bug-step-subshell >> >> FAIL: test-complete >> >> PASS: test-debug >> >> PASS: test-delete >> >> PASS: test-export >> >> PASS: test-file-with-spaces >> >> PASS: test-info-args >> >> FAIL: test-interrupt >> >> PASS: test-misc >> >> PASS: test-setshow >> >> FAIL: test-sig >> >> PASS: test-action >> >> PASS: test-brkpt >> >> PASS: test-bug-args >> >> PASS: test-bugI >> >> PASS: test-bugIFS >> >> PASS: test-bug-loc >> >> PASS: test-bug-source >> >> PASS: test-command >> >> PASS: test-display >> >> PASS: test-enable >> >> PASS: test-finish >> >> PASS: test-frame >> >> PASS: test-list >> >> FAIL: test-lopts >> >> PASS: test-multi >> >> PASS: test-parm >> >> PASS: test-restart >> >> PASS: test-search >> >> FAIL: test-settrace >> >> PASS: test-skip >> >> FAIL: test-sopts >> >> FAIL: test-bug-break >> >> PASS: test-bug-clear >> >> PASS: test-bug-step >> >> PASS: test-subshell >> >> PASS: test-tbreak >> >> FAIL: test-trace >> >> PASS: test-watch1 >> >> PASS: test-watch2 >> >> ============================================================ >> >> ================ >> >> Testsuite summary for bashdb 4.4-0.92 >> >> ============================================================ >> >> ================ >> >> # TOTAL: 42 >> >> # PASS: 33 >> >> # SKIP: 0 >> >> # XFAIL: 0 >> >> # FAIL: 9 >> >> # XPASS: 0 >> >> # ERROR: 0 >> >> ============================================================ >> >> ================ >> >> See test/integration/test-suite.log >> >> Please report to bas...@li... >> >> ============================================================ >> >> ================ >> >> >> >> -- >> >> Jean-Christophe >> >> ------------------------------------------------------------ >> >> ------------------ >> >> Check out the vibrant tech community on one of the world's most >> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> _______________________________________________ >> >> Bashdb-devel mailing list >> >> Bas...@li... >> >> https://lists.sourceforge.net/lists/listinfo/bashdb-devel >> >> >> > >> > >> >> >> -- >> Jean-Christophe >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Bashdb-devel mailing list >> Bas...@li... >> https://lists.sourceforge.net/lists/listinfo/bashdb-devel >> > > |
From: Rocky B. <ro...@gn...> - 2017-06-04 13:52:47
|
Uh, ok. Just send test/integration/test-suite.log I suggested before to me. I don't think people on the devel list are interested in the specific differences. I'll look at when I get a chance, but it might not be for a while. On Sun, Jun 4, 2017 at 9:48 AM, jean-christophe manciot < act...@gm...> wrote: > I never tried to build bashdb with bash 4.3, but with earlier bashdb git > commits (such as the latest ones in december 2016), I had fewer failed > tests (4) vs 9 today. > > On Sun, Jun 4, 2017 at 3:38 PM, Rocky Bernstein <ro...@gn...> wrote: > > > Thanks - I'll look at this when I get a chance. Some general information > > and then some general questions. > > > > The failing integration tests look are the tests that are most fragile > and > > can change with bash release. Generally it's nothing serious, in that it > is > > the test that is wrong, not the functioning of bashdb. > > > > To verify this belief, look at the file test/integration/test-suite.log > > as the above output suggests. You should see diff-style output showing > what > > was expected and what you got instead. Send it to me directly and I'll > look. > > > > Just today earlier I was working on detecting the terminal background and > > whether it was dark or light, and I recall a lot of failures in the same > > files listed above. Most of what I had to do was make sure to pass the - > > -no-highlight option in the tests to make output checking more > > predictable. The kinds if differences I was seeing was in adding ansi > > escape sequences for marking the output that I was getting but wasn't > > expected. > > > > Are you working off of sourceforge git or the last release? If git, make > > sure to "git pull" since this changed a little while ago. > > > > The other place where tests start failing is on a new release (from > > bashdb's standpoint) of bash. I am not sure I have tried version 4.4 yet. > > (I might have but I don't remember) > > Is this the first time you've tried bashdb with bash version 4.4? With > > bash 4.3 that works, right? > > > > > > > > > > On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot < > > act...@gm...> wrote: > > > >> distribution: Ubuntu Zesty > >> bash sources: https://packages.debian.org/source/stretch/bash > >> bash version: 4.4.12(1) (built from latest debian 4.4-5) > >> bashdb sources: git://git.code.sf.net/p/bashdb/code > >> bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016 > >> bashdb configure options: > >> --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \ > >> --build=x86_64-pc-linux-gnu \ > >> --prefix=/usr > --sysconfdir=/etc > >> --localstatedir=/var \ > >> --infodir=/usr/share/info > >> --mandir=/usr/share/man > >> bashdb build tool: remake --trace > >> bashdb check tool: make check > >> bashdb tests log: attached test/integration/test-suite.log > >> > >> PASS: test-bug-step-subshell > >> FAIL: test-complete > >> PASS: test-debug > >> PASS: test-delete > >> PASS: test-export > >> PASS: test-file-with-spaces > >> PASS: test-info-args > >> FAIL: test-interrupt > >> PASS: test-misc > >> PASS: test-setshow > >> FAIL: test-sig > >> PASS: test-action > >> PASS: test-brkpt > >> PASS: test-bug-args > >> PASS: test-bugI > >> PASS: test-bugIFS > >> PASS: test-bug-loc > >> PASS: test-bug-source > >> PASS: test-command > >> PASS: test-display > >> PASS: test-enable > >> PASS: test-finish > >> PASS: test-frame > >> PASS: test-list > >> FAIL: test-lopts > >> PASS: test-multi > >> PASS: test-parm > >> PASS: test-restart > >> PASS: test-search > >> FAIL: test-settrace > >> PASS: test-skip > >> FAIL: test-sopts > >> FAIL: test-bug-break > >> PASS: test-bug-clear > >> PASS: test-bug-step > >> PASS: test-subshell > >> PASS: test-tbreak > >> FAIL: test-trace > >> PASS: test-watch1 > >> PASS: test-watch2 > >> ============================================================ > >> ================ > >> Testsuite summary for bashdb 4.4-0.92 > >> ============================================================ > >> ================ > >> # TOTAL: 42 > >> # PASS: 33 > >> # SKIP: 0 > >> # XFAIL: 0 > >> # FAIL: 9 > >> # XPASS: 0 > >> # ERROR: 0 > >> ============================================================ > >> ================ > >> See test/integration/test-suite.log > >> Please report to bas...@li... > >> ============================================================ > >> ================ > >> > >> -- > >> Jean-Christophe > >> ------------------------------------------------------------ > >> ------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> _______________________________________________ > >> Bashdb-devel mailing list > >> Bas...@li... > >> https://lists.sourceforge.net/lists/listinfo/bashdb-devel > >> > > > > > > > -- > Jean-Christophe > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > |
From: jean-christophe m. <act...@gm...> - 2017-06-04 13:48:31
|
I never tried to build bashdb with bash 4.3, but with earlier bashdb git commits (such as the latest ones in december 2016), I had fewer failed tests (4) vs 9 today. On Sun, Jun 4, 2017 at 3:38 PM, Rocky Bernstein <ro...@gn...> wrote: > Thanks - I'll look at this when I get a chance. Some general information > and then some general questions. > > The failing integration tests look are the tests that are most fragile and > can change with bash release. Generally it's nothing serious, in that it is > the test that is wrong, not the functioning of bashdb. > > To verify this belief, look at the file test/integration/test-suite.log > as the above output suggests. You should see diff-style output showing what > was expected and what you got instead. Send it to me directly and I'll look. > > Just today earlier I was working on detecting the terminal background and > whether it was dark or light, and I recall a lot of failures in the same > files listed above. Most of what I had to do was make sure to pass the - > -no-highlight option in the tests to make output checking more > predictable. The kinds if differences I was seeing was in adding ansi > escape sequences for marking the output that I was getting but wasn't > expected. > > Are you working off of sourceforge git or the last release? If git, make > sure to "git pull" since this changed a little while ago. > > The other place where tests start failing is on a new release (from > bashdb's standpoint) of bash. I am not sure I have tried version 4.4 yet. > (I might have but I don't remember) > Is this the first time you've tried bashdb with bash version 4.4? With > bash 4.3 that works, right? > > > > > On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot < > act...@gm...> wrote: > >> distribution: Ubuntu Zesty >> bash sources: https://packages.debian.org/source/stretch/bash >> bash version: 4.4.12(1) (built from latest debian 4.4-5) >> bashdb sources: git://git.code.sf.net/p/bashdb/code >> bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016 >> bashdb configure options: >> --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \ >> --build=x86_64-pc-linux-gnu \ >> --prefix=/usr --sysconfdir=/etc >> --localstatedir=/var \ >> --infodir=/usr/share/info >> --mandir=/usr/share/man >> bashdb build tool: remake --trace >> bashdb check tool: make check >> bashdb tests log: attached test/integration/test-suite.log >> >> PASS: test-bug-step-subshell >> FAIL: test-complete >> PASS: test-debug >> PASS: test-delete >> PASS: test-export >> PASS: test-file-with-spaces >> PASS: test-info-args >> FAIL: test-interrupt >> PASS: test-misc >> PASS: test-setshow >> FAIL: test-sig >> PASS: test-action >> PASS: test-brkpt >> PASS: test-bug-args >> PASS: test-bugI >> PASS: test-bugIFS >> PASS: test-bug-loc >> PASS: test-bug-source >> PASS: test-command >> PASS: test-display >> PASS: test-enable >> PASS: test-finish >> PASS: test-frame >> PASS: test-list >> FAIL: test-lopts >> PASS: test-multi >> PASS: test-parm >> PASS: test-restart >> PASS: test-search >> FAIL: test-settrace >> PASS: test-skip >> FAIL: test-sopts >> FAIL: test-bug-break >> PASS: test-bug-clear >> PASS: test-bug-step >> PASS: test-subshell >> PASS: test-tbreak >> FAIL: test-trace >> PASS: test-watch1 >> PASS: test-watch2 >> ============================================================ >> ================ >> Testsuite summary for bashdb 4.4-0.92 >> ============================================================ >> ================ >> # TOTAL: 42 >> # PASS: 33 >> # SKIP: 0 >> # XFAIL: 0 >> # FAIL: 9 >> # XPASS: 0 >> # ERROR: 0 >> ============================================================ >> ================ >> See test/integration/test-suite.log >> Please report to bas...@li... >> ============================================================ >> ================ >> >> -- >> Jean-Christophe >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Bashdb-devel mailing list >> Bas...@li... >> https://lists.sourceforge.net/lists/listinfo/bashdb-devel >> > > -- Jean-Christophe |
From: Rocky B. <ro...@gn...> - 2017-06-04 13:39:08
|
Thanks - I'll look at this when I get a chance. Some general information and then some general questions. The failing integration tests look are the tests that are most fragile and can change with bash release. Generally it's nothing serious, in that it is the test that is wrong, not the functioning of bashdb. To verify this belief, look at the file test/integration/test-suite.log as the above output suggests. You should see diff-style output showing what was expected and what you got instead. Send it to me directly and I'll look. Just today earlier I was working on detecting the terminal background and whether it was dark or light, and I recall a lot of failures in the same files listed above. Most of what I had to do was make sure to pass the - -no-highlight option in the tests to make output checking more predictable. The kinds if differences I was seeing was in adding ansi escape sequences for marking the output that I was getting but wasn't expected. Are you working off of sourceforge git or the last release? If git, make sure to "git pull" since this changed a little while ago. The other place where tests start failing is on a new release (from bashdb's standpoint) of bash. I am not sure I have tried version 4.4 yet. (I might have but I don't remember) Is this the first time you've tried bashdb with bash version 4.4? With bash 4.3 that works, right? On Sun, Jun 4, 2017 at 9:03 AM, jean-christophe manciot < act...@gm...> wrote: > distribution: Ubuntu Zesty > bash sources: https://packages.debian.org/source/stretch/bash > bash version: 4.4.12(1) (built from latest debian 4.4-5) > bashdb sources: git://git.code.sf.net/p/bashdb/code > bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016 > bashdb configure options: > --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \ > --build=x86_64-pc-linux-gnu \ > --prefix=/usr --sysconfdir=/etc > --localstatedir=/var \ > --infodir=/usr/share/info > --mandir=/usr/share/man > bashdb build tool: remake --trace > bashdb check tool: make check > bashdb tests log: attached test/integration/test-suite.log > > PASS: test-bug-step-subshell > FAIL: test-complete > PASS: test-debug > PASS: test-delete > PASS: test-export > PASS: test-file-with-spaces > PASS: test-info-args > FAIL: test-interrupt > PASS: test-misc > PASS: test-setshow > FAIL: test-sig > PASS: test-action > PASS: test-brkpt > PASS: test-bug-args > PASS: test-bugI > PASS: test-bugIFS > PASS: test-bug-loc > PASS: test-bug-source > PASS: test-command > PASS: test-display > PASS: test-enable > PASS: test-finish > PASS: test-frame > PASS: test-list > FAIL: test-lopts > PASS: test-multi > PASS: test-parm > PASS: test-restart > PASS: test-search > FAIL: test-settrace > PASS: test-skip > FAIL: test-sopts > FAIL: test-bug-break > PASS: test-bug-clear > PASS: test-bug-step > PASS: test-subshell > PASS: test-tbreak > FAIL: test-trace > PASS: test-watch1 > PASS: test-watch2 > ============================================================ > ================ > Testsuite summary for bashdb 4.4-0.92 > ============================================================ > ================ > # TOTAL: 42 > # PASS: 33 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 9 > # XPASS: 0 > # ERROR: 0 > ============================================================ > ================ > See test/integration/test-suite.log > Please report to bas...@li... > ============================================================ > ================ > > -- > Jean-Christophe > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > |
From: jean-christophe m. <act...@gm...> - 2017-06-04 13:03:44
|
distribution: Ubuntu Zesty bash sources: https://packages.debian.org/source/stretch/bash bash version: 4.4.12(1) (built from latest debian 4.4-5) bashdb sources: git://git.code.sf.net/p/bashdb/code bashdb commit: 4e1479d18829a4de1081b936a4976ac534007016 bashdb configure options: --with-bash-src=/home/actionmystique/src/Bash/bash-4.4-5 \ --build=x86_64-pc-linux-gnu \ --prefix=/usr --sysconfdir=/etc --localstatedir=/var \ --infodir=/usr/share/info --mandir=/usr/share/man bashdb build tool: remake --trace bashdb check tool: make check bashdb tests log: attached test/integration/test-suite.log PASS: test-bug-step-subshell FAIL: test-complete PASS: test-debug PASS: test-delete PASS: test-export PASS: test-file-with-spaces PASS: test-info-args FAIL: test-interrupt PASS: test-misc PASS: test-setshow FAIL: test-sig PASS: test-action PASS: test-brkpt PASS: test-bug-args PASS: test-bugI PASS: test-bugIFS PASS: test-bug-loc PASS: test-bug-source PASS: test-command PASS: test-display PASS: test-enable PASS: test-finish PASS: test-frame PASS: test-list FAIL: test-lopts PASS: test-multi PASS: test-parm PASS: test-restart PASS: test-search FAIL: test-settrace PASS: test-skip FAIL: test-sopts FAIL: test-bug-break PASS: test-bug-clear PASS: test-bug-step PASS: test-subshell PASS: test-tbreak FAIL: test-trace PASS: test-watch1 PASS: test-watch2 ============================================================================ Testsuite summary for bashdb 4.4-0.92 ============================================================================ # TOTAL: 42 # PASS: 33 # SKIP: 0 # XFAIL: 0 # FAIL: 9 # XPASS: 0 # ERROR: 0 ============================================================================ See test/integration/test-suite.log Please report to bas...@li... ============================================================================ -- Jean-Christophe |
From: Doug S. <do...@mi...> - 2017-01-26 07:04:56
|
From: Rocky B. <roc...@gm...> - 2017-01-19 12:10:12
|
The short story is that probably everything's okay, and even if not this is not likely to have an impact on using it that you'd notice. The integration tests are a little fragile which means they are often breaking when output changes slightly and should be reworked to make them less so. But I'm probably not going to spend the time to do so and that means that no one else will either. The longer story is that from summary information alone, one has very little information to try to fix. At a minimum one needs the version of bash and as it says in the put you do have, the log file as more information like which test failed and what result it gave. When I just tried running current git sources on GNU bash, version 4.3.46(1)-release (x86_64-pc-linux-gnu) I got one failure in test-watch and it is failing because the line number inside the debugger program has change from line 98 to line 95 which is most likely an output update bug on my part. I know the output instructions say send to this list when you hit a failure, and so I appreciate that you followed those instructions. (Those instruction though too are kind of the boilerplate default when one uses gnu automake/autoconf.) On Wed, Jan 18, 2017 at 9:07 PM, Richard Steiger <rst...@bp...> wrote: > FYI, getting the following errors in response to “make & make check” > incantation: > ============================================================ > ================ > Testsuite summary for bashdb 4.4-0.92 > ============================================================ > ================ > # TOTAL: 42 > # PASS: 33 > # SKIP: 5 > # XFAIL: 0 > # FAIL: 4 > # XPASS: 0 > # ERROR: 0 > ============================================================ > ================ > See test/integration/test-suite.log > Please report to bas...@li... > ============================================================ > ================ > make[4]: *** [test-suite.log] Error 1 > make[3]: *** [check-TESTS] Error 2 > make[2]: *** [check-am] Error 2 > make[1]: *** [check-recursive] Error 1 > make: *** [check-recursive] Error 1 > > No need to respond, unless the above indicates problems that will prevent > bashdb from working properly. > > Regards, > -rjs > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > |
From: Richard S. <rst...@bp...> - 2017-01-19 04:40:36
|
FYI, getting the following errors in response to “make & make check” incantation: ============================================================================ Testsuite summary for bashdb 4.4-0.92 ============================================================================ # TOTAL: 42 # PASS: 33 # SKIP: 5 # XFAIL: 0 # FAIL: 4 # XPASS: 0 # ERROR: 0 ============================================================================ See test/integration/test-suite.log Please report to bas...@li... ============================================================================ make[4]: *** [test-suite.log] Error 1 make[3]: *** [check-TESTS] Error 2 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 No need to respond, unless the above indicates problems that will prevent bashdb from working properly. Regards, -rjs |
From: jean-christophe m. <act...@gm...> - 2016-12-07 10:21:46
|
------------------------------------------------------------------------------------------------------------ bashdb .drive-filter-files-list bash debugger, bashdb, release 4.4-0.92 Copyright 2002, 2003, 2004, 2006-2012, 2014, 2016 Rocky Bernstein This 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. (/usr/bin/.drive-filter-files-list:86): 86: shopt -s extglob bashdb<0> set args .driveinclude local sync bashdb<1> break 136 Breakpoint 1 set in file /usr/bin/.drive-filter-files-list, line 136. bashdb<2> R *Restarting with: /bin/bashdb .driveinclude local sync * /usr/share/share/bashdb/command/run.sh: line 75: cd: too many arguments bash debugger, bashdb, release 4.4-0.92 Copyright 2002, 2003, 2004, 2006-2012, 2014, 2016 Rocky Bernstein This 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. (/bin/bashdb:1): 1: #!/bin/bash ------------------------------------------------------------------------------------------------------------ R should rather call ".drive-filter-files-list .driveinclude local sync" in this example. -- Jean-Christophe |
From: Rocky B. <roc...@gm...> - 2016-12-03 21:37:23
|
One last little thing. Just because you *think *you have configured not to compile files needing bash source, that doesn't necessarily mean that was the case. That's why details are important. It definitely looks like the configuration was set to try to build source. And the fact that read.c didn't barf in finding bash headers (but instead elsewhere) supports that belief. At the end of the configure script we dump what's up. For example: Location : /bin/bash Prefix : /usr/share prefix checks out We will try to build the set0 builtin to set variable $0 using source located at /src/build/bash-4.4. That import output was omitted in your log. But even if the "Will try to" line was missing since the configure run wasn't clean that too may be suspect. So the next thing I would look at is config.status and for the configuration above we would have S["BASH_SRC"]="/src/build/bash-4.4" But independent of any of this the fact that read.c was compiled means that the configuration was most likely somehow with some sort of bash source set. remake -x on a run will often also elucidate what's happening in a build. On Sat, Dec 3, 2016 at 3:24 PM, Rocky Bernstein <roc...@gm...> wrote: > Ok. Looked at this more. As I said, bash 4.4 changes the API > vaid_array_reference. As best as I can tell, it just breaks the old API > without adding anything. > > As for the ac_aux_dir problems, I get that too now. That too seems to be a > difference in how autoconf and automake work over the years and what they > now expect. > > Commit 68d03c3a85252447e04a87a686c7b14ae18616d should address both of > these. > > On Sat, Dec 3, 2016 at 11:42 AM, jean-christophe manciot < > act...@gm...> wrote: > >> Here are the details you've asked for: >> bash --version >> GNU bash, version 4.4.0(1)-release >> on Ubuntu 16.10 4.8 >> >> You have missed the fact that the configure line with --with-bash-src=... >> has been *commented out* because of the bug described in the comment >> located just above it and not reported. It has no effect in this bug >> report. >> >> The log & bug reported by this mail is the consequence of the non >> commented configure & make lines. >> >> On Sat, Dec 3, 2016 at 3:48 PM, Rocky Bernstein < >> roc...@gm...> wrote: >> >>> Jean-Christophe - >>> >>> Thanks for reporting the problems you encountered. I have a little >>> trouble reading the report because, although there is a bit that is >>> specific, various oher details aren't there. >>> >>> So here's my take on what the log given. >>> >>> 'readc.c:848:46: error: too few arguments to function >>>> ‘valid_array_reference’' >>> >>> >>> is probably caused by a change in the bash API to the function >>> valid_array_reference(). >>> The offending line in bashdb is: >>> >>> if (legal_identifier (varname) == 0 && valid_array_reference >>> (varname) == 0) >>> >>> What version of bash did you run against? If you or someone eise in the >>> devel lis is up for it, perhaps you can figure how to change read.c for the >>> changed var_array_reference call. >>> >>> If you remove --with-bash-src=/home/actionmystique/Program-Files/ >>> Ubuntu/Bash/git-bash from the configure option, bashdb won't try to >>> compile read.c. >>> >>> That particular function that is getting compiled allows bashdb to do a >>> command-completion kind of read inside it debugger read loop. It not needed >>> for overall basic functioning, but I guess it is a nice thing to have. >>> Perhaps bash now offers a way to handle completion inside its builtin >>> read() function. If that's the case we should remove compiling this. >>> Perhaps you or someone can check? >>> >>> As for setting $ac_aux_dir to '.', that may work for you in your >>> environment but it is symptomatic of some sort of configure script failure. >>> Any shell variable that starts ac_ is something the configure script sets >>> (ac stands I guess for autoconf). So if this is set wrong or is not set, >>> then things are probably misconfigured. When bashdb is misconfigured, the >>> test scripts may fail. >>> >>> >>> On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot < >>> act...@gm...> wrote: >>> >>>> Hi there, >>>> >>>> The following script run with branch=master & tag=release-4.4-0.92: >>>> >>>> echo -------- >>>> echo Cleaning >>>> echo -------- >>>> cd git-bashdb >>>> sudo -u actionmystique -H git-reset-clean-pull-checkout.sh >>>> $branch >>>> $tag >>>> >>>> echo ------------------ >>>> echo Building configure >>>> echo ------------------ >>>> export NOCONFIGURE=yes >>>> sudo -Eu actionmystique -H ./autogen.sh >>>> >>>> echo ------------------------------------------------------- >>>> echo Working around a bug related to $ac_aux_dir/config.sub >>>> echo ------------------------------------------------------- >>>> # Cf. https://sourceforge.net/p/bashdb/bugs/42/ >>>> sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure >>>> >>>> echo ----------- >>>> echo Configuring >>>> echo ----------- >>>> # Bugs 'readc.c:848:46: error: too few arguments to function >>>> ‘valid_array_reference’' >>>> # sudo -u actionmystique -H ./configure >>>> --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash >>>> \ >>>> sudo -u actionmystique -H ./configure --prefix=/usr/share >>>> --sysconfdir=/etc --localstatedir=/var >>>> >>>> echo --------- >>>> echo Compiling >>>> echo --------- >>>> sudo -u actionmystique -H make >>>> >>>> echo -------- >>>> echo Checking >>>> echo -------- >>>> sudo -u actionmystique -H make check >>>> >>>> leads to *5 tests errors: attached test-suite.log* >>>> >>>> The whole build log is available on request. >>>> -- >>>> Jean-Christophe >>>> >>>> ------------------------------------------------------------ >>>> ------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Bashdb-devel mailing list >>>> Bas...@li... >>>> https://lists.sourceforge.net/lists/listinfo/bashdb-devel >>>> >>>> >>> >> >> >> -- >> Jean-Christophe >> > > |
From: Rocky B. <roc...@gm...> - 2016-12-03 20:24:38
|
Ok. Looked at this more. As I said, bash 4.4 changes the API vaid_array_reference. As best as I can tell, it just breaks the old API without adding anything. As for the ac_aux_dir problems, I get that too now. That too seems to be a difference in how autoconf and automake work over the years and what they now expect. Commit 68d03c3a85252447e04a87a686c7b14ae18616d should address both of these. On Sat, Dec 3, 2016 at 11:42 AM, jean-christophe manciot < act...@gm...> wrote: > Here are the details you've asked for: > bash --version > GNU bash, version 4.4.0(1)-release > on Ubuntu 16.10 4.8 > > You have missed the fact that the configure line with --with-bash-src=... > has been *commented out* because of the bug described in the comment > located just above it and not reported. It has no effect in this bug > report. > > The log & bug reported by this mail is the consequence of the non > commented configure & make lines. > > On Sat, Dec 3, 2016 at 3:48 PM, Rocky Bernstein <roc...@gm... > > wrote: > >> Jean-Christophe - >> >> Thanks for reporting the problems you encountered. I have a little >> trouble reading the report because, although there is a bit that is >> specific, various oher details aren't there. >> >> So here's my take on what the log given. >> >> 'readc.c:848:46: error: too few arguments to function >>> ‘valid_array_reference’' >> >> >> is probably caused by a change in the bash API to the function >> valid_array_reference(). >> The offending line in bashdb is: >> >> if (legal_identifier (varname) == 0 && valid_array_reference >> (varname) == 0) >> >> What version of bash did you run against? If you or someone eise in the >> devel lis is up for it, perhaps you can figure how to change read.c for the >> changed var_array_reference call. >> >> If you remove --with-bash-src=/home/actionmystique/Program-Files/ >> Ubuntu/Bash/git-bash from the configure option, bashdb won't try to >> compile read.c. >> >> That particular function that is getting compiled allows bashdb to do a >> command-completion kind of read inside it debugger read loop. It not needed >> for overall basic functioning, but I guess it is a nice thing to have. >> Perhaps bash now offers a way to handle completion inside its builtin >> read() function. If that's the case we should remove compiling this. >> Perhaps you or someone can check? >> >> As for setting $ac_aux_dir to '.', that may work for you in your >> environment but it is symptomatic of some sort of configure script failure. >> Any shell variable that starts ac_ is something the configure script sets >> (ac stands I guess for autoconf). So if this is set wrong or is not set, >> then things are probably misconfigured. When bashdb is misconfigured, the >> test scripts may fail. >> >> >> On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot < >> act...@gm...> wrote: >> >>> Hi there, >>> >>> The following script run with branch=master & tag=release-4.4-0.92: >>> >>> echo -------- >>> echo Cleaning >>> echo -------- >>> cd git-bashdb >>> sudo -u actionmystique -H git-reset-clean-pull-checkout.sh >>> $branch >>> $tag >>> >>> echo ------------------ >>> echo Building configure >>> echo ------------------ >>> export NOCONFIGURE=yes >>> sudo -Eu actionmystique -H ./autogen.sh >>> >>> echo ------------------------------------------------------- >>> echo Working around a bug related to $ac_aux_dir/config.sub >>> echo ------------------------------------------------------- >>> # Cf. https://sourceforge.net/p/bashdb/bugs/42/ >>> sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure >>> >>> echo ----------- >>> echo Configuring >>> echo ----------- >>> # Bugs 'readc.c:848:46: error: too few arguments to function >>> ‘valid_array_reference’' >>> # sudo -u actionmystique -H ./configure >>> --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash >>> \ >>> sudo -u actionmystique -H ./configure --prefix=/usr/share >>> --sysconfdir=/etc --localstatedir=/var >>> >>> echo --------- >>> echo Compiling >>> echo --------- >>> sudo -u actionmystique -H make >>> >>> echo -------- >>> echo Checking >>> echo -------- >>> sudo -u actionmystique -H make check >>> >>> leads to *5 tests errors: attached test-suite.log* >>> >>> The whole build log is available on request. >>> -- >>> Jean-Christophe >>> >>> ------------------------------------------------------------ >>> ------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Bashdb-devel mailing list >>> Bas...@li... >>> https://lists.sourceforge.net/lists/listinfo/bashdb-devel >>> >>> >> > > > -- > Jean-Christophe > |
From: jean-christophe m. <act...@gm...> - 2016-12-03 16:42:55
|
Here are the details you've asked for: bash --version GNU bash, version 4.4.0(1)-release on Ubuntu 16.10 4.8 You have missed the fact that the configure line with --with-bash-src=... has been *commented out* because of the bug described in the comment located just above it and not reported. It has no effect in this bug report. The log & bug reported by this mail is the consequence of the non commented configure & make lines. On Sat, Dec 3, 2016 at 3:48 PM, Rocky Bernstein <roc...@gm...> wrote: > Jean-Christophe - > > Thanks for reporting the problems you encountered. I have a little trouble > reading the report because, although there is a bit that is specific, > various oher details aren't there. > > So here's my take on what the log given. > > 'readc.c:848:46: error: too few arguments to function >> ‘valid_array_reference’' > > > is probably caused by a change in the bash API to the function > valid_array_reference(). > The offending line in bashdb is: > > if (legal_identifier (varname) == 0 && valid_array_reference > (varname) == 0) > > What version of bash did you run against? If you or someone eise in the > devel lis is up for it, perhaps you can figure how to change read.c for the > changed var_array_reference call. > > If you remove --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash > from the configure option, bashdb won't try to compile read.c. > > That particular function that is getting compiled allows bashdb to do a > command-completion kind of read inside it debugger read loop. It not needed > for overall basic functioning, but I guess it is a nice thing to have. > Perhaps bash now offers a way to handle completion inside its builtin > read() function. If that's the case we should remove compiling this. > Perhaps you or someone can check? > > As for setting $ac_aux_dir to '.', that may work for you in your > environment but it is symptomatic of some sort of configure script failure. > Any shell variable that starts ac_ is something the configure script sets > (ac stands I guess for autoconf). So if this is set wrong or is not set, > then things are probably misconfigured. When bashdb is misconfigured, the > test scripts may fail. > > > On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot < > act...@gm...> wrote: > >> Hi there, >> >> The following script run with branch=master & tag=release-4.4-0.92: >> >> echo -------- >> echo Cleaning >> echo -------- >> cd git-bashdb >> sudo -u actionmystique -H git-reset-clean-pull-checkout.sh >> $branch >> $tag >> >> echo ------------------ >> echo Building configure >> echo ------------------ >> export NOCONFIGURE=yes >> sudo -Eu actionmystique -H ./autogen.sh >> >> echo ------------------------------------------------------- >> echo Working around a bug related to $ac_aux_dir/config.sub >> echo ------------------------------------------------------- >> # Cf. https://sourceforge.net/p/bashdb/bugs/42/ >> sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure >> >> echo ----------- >> echo Configuring >> echo ----------- >> # Bugs 'readc.c:848:46: error: too few arguments to function >> ‘valid_array_reference’' >> # sudo -u actionmystique -H ./configure >> --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash \ >> sudo -u actionmystique -H ./configure --prefix=/usr/share >> --sysconfdir=/etc --localstatedir=/var >> >> echo --------- >> echo Compiling >> echo --------- >> sudo -u actionmystique -H make >> >> echo -------- >> echo Checking >> echo -------- >> sudo -u actionmystique -H make check >> >> leads to *5 tests errors: attached test-suite.log* >> >> The whole build log is available on request. >> -- >> Jean-Christophe >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot >> _______________________________________________ >> Bashdb-devel mailing list >> Bas...@li... >> https://lists.sourceforge.net/lists/listinfo/bashdb-devel >> >> > -- Jean-Christophe |
From: Rocky B. <roc...@gm...> - 2016-12-03 14:48:22
|
Jean-Christophe - Thanks for reporting the problems you encountered. I have a little trouble reading the report because, although there is a bit that is specific, various oher details aren't there. So here's my take on what the log given. 'readc.c:848:46: error: too few arguments to function > ‘valid_array_reference’' is probably caused by a change in the bash API to the function valid_array_reference(). The offending line in bashdb is: if (legal_identifier (varname) == 0 && valid_array_reference (varname) == 0) What version of bash did you run against? If you or someone eise in the devel lis is up for it, perhaps you can figure how to change read.c for the changed var_array_reference call. If you remove --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash from the configure option, bashdb won't try to compile read.c. That particular function that is getting compiled allows bashdb to do a command-completion kind of read inside it debugger read loop. It not needed for overall basic functioning, but I guess it is a nice thing to have. Perhaps bash now offers a way to handle completion inside its builtin read() function. If that's the case we should remove compiling this. Perhaps you or someone can check? As for setting $ac_aux_dir to '.', that may work for you in your environment but it is symptomatic of some sort of configure script failure. Any shell variable that starts ac_ is something the configure script sets (ac stands I guess for autoconf). So if this is set wrong or is not set, then things are probably misconfigured. When bashdb is misconfigured, the test scripts may fail. On Fri, Dec 2, 2016 at 2:25 PM, jean-christophe manciot < act...@gm...> wrote: > Hi there, > > The following script run with branch=master & tag=release-4.4-0.92: > > echo -------- > echo Cleaning > echo -------- > cd git-bashdb > sudo -u actionmystique -H git-reset-clean-pull-checkout.sh $branch > $tag > > echo ------------------ > echo Building configure > echo ------------------ > export NOCONFIGURE=yes > sudo -Eu actionmystique -H ./autogen.sh > > echo ------------------------------------------------------- > echo Working around a bug related to $ac_aux_dir/config.sub > echo ------------------------------------------------------- > # Cf. https://sourceforge.net/p/bashdb/bugs/42/ > sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure > > echo ----------- > echo Configuring > echo ----------- > # Bugs 'readc.c:848:46: error: too few arguments to function > ‘valid_array_reference’' > # sudo -u actionmystique -H ./configure > --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash \ > sudo -u actionmystique -H ./configure --prefix=/usr/share > --sysconfdir=/etc --localstatedir=/var > > echo --------- > echo Compiling > echo --------- > sudo -u actionmystique -H make > > echo -------- > echo Checking > echo -------- > sudo -u actionmystique -H make check > > leads to *5 tests errors: attached test-suite.log* > > The whole build log is available on request. > -- > Jean-Christophe > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > > |
From: jean-christophe m. <act...@gm...> - 2016-12-02 19:25:42
|
Hi there, The following script run with branch=master & tag=release-4.4-0.92: echo -------- echo Cleaning echo -------- cd git-bashdb sudo -u actionmystique -H git-reset-clean-pull-checkout.sh $branch $tag echo ------------------ echo Building configure echo ------------------ export NOCONFIGURE=yes sudo -Eu actionmystique -H ./autogen.sh echo ------------------------------------------------------- echo Working around a bug related to $ac_aux_dir/config.sub echo ------------------------------------------------------- # Cf. https://sourceforge.net/p/bashdb/bugs/42/ sudo -u actionmystique -H sed -i 's|$ac_aux_dir|.|g' ./configure echo ----------- echo Configuring echo ----------- # Bugs 'readc.c:848:46: error: too few arguments to function ‘valid_array_reference’' # sudo -u actionmystique -H ./configure --with-bash-src=/home/actionmystique/Program-Files/Ubuntu/Bash/git-bash \ sudo -u actionmystique -H ./configure --prefix=/usr/share --sysconfdir=/etc --localstatedir=/var echo --------- echo Compiling echo --------- sudo -u actionmystique -H make echo -------- echo Checking echo -------- sudo -u actionmystique -H make check leads to *5 tests errors: attached test-suite.log* The whole build log is available on request. -- Jean-Christophe |
From: Rocky B. <roc...@gm...> - 2016-03-12 10:17:46
|
This failure means that debugger signal handing is not working for you. This is a debugger is for bash 3.x, and that specific debugger code is about 9 years old. I am not going to be further developing code this old. But if others are so motivated to do so, I'll accept patches. For that to happen, unless it is yourself, the person helping you would probably need to know the OS and version of bash you are using. On Sat, Mar 12, 2016 at 4:20 AM, Song,Ruogang <ruo...@pa...> wrote: > > > --- /tmp/sig.check 2016-03-12 17:16:57.000000000 +0800 > +++ /cpic/sxxsjs/cs1/bashdb-3.1-0.09/test/sig.right 2007-10-14 > 15:27:46.000000000 +0800 > @@ -21,6 +21,7 @@ > +handle TERM bogus > Need to give a command: stop, nostop, stack, nostack, print, noprint > +eval kill -TERM $$ > +Program received signal SIGTERM (15)... > +### Should not have printed a stack trace above... > +handle TERM noprint > +handle TERM stack > @@ -37,11 +38,20 @@ > SIGTERM stop noprint showstack trap -- '_Dbg_sig_handler 15 > "$BASH_COMMAND" "$@"' SIGTERM > +continue > Program received signal SIGTERM (15)... > -->0 in file `sig.sh' at line 17 > -##1 source("sig.sh") called from file `bashdb' at line 277 > -->2 main() called from file `bashdb' at line 0 > +->0 in file `dbg-cmds.inc' at line 2 > +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `dbg-cmds.inc' > at line 343 > +->2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `dbg-cmds.inc' > at line 157 > +##3 _Dbg_cmdloop() called from file `dbg-sig.inc' at line 220 > +##4 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file > `sig.sh' at line 7 > +##5 source("sig.sh") called from file `bashdb' at line 277 > +##6 main() called from file `bashdb' at line 0 > +### Should have printed a stack trace above... > +continue > ++where > +->0 in file `sig.sh' at line 741 > +##1 source("sig.sh") called from file `bashdb' at line 277 > +##2 main() called from file `bashdb' at line 0 > ++continue > Program received signal SIGINT (2)... > ->0 in file `sig.sh' at line 23 > ##1 source("sig.sh") called from file `bashdb' at line 277 > @@ -51,9 +61,5 @@ > ##1 source("sig.sh") called from file `bashdb' at line 277 > ->2 main() called from file `bashdb' at line 0 > Debugged program terminated normally. Use q to quit or R to restart. > -+where > -No stack. > -+continue > -The program is not being run. > +kill > sig.tests: line 11: xxxx Killed $BASH ${TOP_BUILDDIR}bashdb -B -q -L .. > -x $cmdfile $debugged_script > --- /tmp/sig.check2 2016-03-12 17:16:57.000000000 +0800 > +++ /tmp/sig.right 2016-03-12 17:16:57.000000000 +0800 > @@ -21,6 +21,7 @@ > +handle TERM bogus > Need to give a command: stop, nostop, stack, nostack, print, noprint > +eval kill -TERM $$ > +Program received signal SIGTERM (15)... > +### Should not have printed a stack trace above... > +handle TERM noprint > +handle TERM stack > @@ -37,11 +38,20 @@ > SIGTERM stop noprint showstack trap -- '_Dbg_sig_handler 15 > "$BASH_COMMAND" "$@"' SIGTERM > +continue > Program received signal SIGTERM (15)... > -->0 in file `sig.sh' at line 17 > -##1 source("sig.sh") called from file `bashdb' at line 277 > -->2 main() called from file `bashdb' at line 0 > +->0 in file `dbg-cmds.inc' at line 2 > +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `dbg-cmds.inc' > at line 343 > +->2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `dbg-cmds.inc' > at line 157 > +##3 _Dbg_cmdloop() called from file `dbg-sig.inc' at line 220 > +##4 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file > `sig.sh' at line 7 > +##5 source("sig.sh") called from file `bashdb' at line 277 > +##6 main() called from file `bashdb' at line 0 > +### Should have printed a stack trace above... > +continue > ++where > +->0 in file `sig.sh' at line 741 > +##1 source("sig.sh") called from file `bashdb' at line 277 > +##2 main() called from file `bashdb' at line 0 > ++continue > Program received signal SIGINT (2)... > ->0 in file `sig.sh' at line 23 > ##1 source("sig.sh") called from file `bashdb' at line 277 > @@ -51,9 +61,5 @@ > ##1 source("sig.sh") called from file `bashdb' at line 277 > ->2 main() called from file `bashdb' at line 0 > Debugged program terminated normally. Use q to quit or R to restart. > -+where > -No stack. > -+continue > -The program is not being run. > +kill > sig.tests: line 11: xxxx Killed $BASH ${TOP_BUILDDIR}bashdb -B -q -L .. > -x $cmdfile $debugged_script > FAIL: run-sig > PASS: run-skip > checking subshell1... > checking subshell2... > checking subshell3... > PASS: run-subshell > PASS: run-tbreak > checking trace... > checking trace2... > PASS: run-trace > PASS: run-watch1 > PASS: run-watch2 > =================================================== > 1 of 25 tests failed > Please report to bas...@li... > =================================================== > make[2]: *** [check-TESTS] Error 1 > make[2]: Leaving directory `/cpic/sxxsjs/cs1/bashdb-3.1-0.09/test' > make[1]: *** [check-am] Error 2 > make[1]: Leaving directory `/cpic/sxxsjs/cs1/bashdb-3.1-0.09/test' > make: *** [check-recursive] Error 1 > > > > Best Regards, > [logo+纳斯达克邮件.png] > 宋若刚 > Professional Talent Acquisition > Mobile: +86.136.8219.7690 > Email: ruo...@pa...<mailto:Jac...@pa...> > > > ------------------------------------------------------------------------------ > Transform Data into Opportunity. > Accelerate data analysis in your applications with > Intel Data Analytics Acceleration Library. > Click to learn more. > http://pubads.g.doubleclick.net/gampad/clk?id=278785111&iu=/4140 > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > |
From: Song,Ruogang <ruo...@pa...> - 2016-03-12 09:53:08
|
--- /tmp/sig.check 2016-03-12 17:16:57.000000000 +0800 +++ /cpic/sxxsjs/cs1/bashdb-3.1-0.09/test/sig.right 2007-10-14 15:27:46.000000000 +0800 @@ -21,6 +21,7 @@ +handle TERM bogus Need to give a command: stop, nostop, stack, nostack, print, noprint +eval kill -TERM $$ +Program received signal SIGTERM (15)... +### Should not have printed a stack trace above... +handle TERM noprint +handle TERM stack @@ -37,11 +38,20 @@ SIGTERM stop noprint showstack trap -- '_Dbg_sig_handler 15 "$BASH_COMMAND" "$@"' SIGTERM +continue Program received signal SIGTERM (15)... -->0 in file `sig.sh' at line 17 -##1 source("sig.sh") called from file `bashdb' at line 277 -->2 main() called from file `bashdb' at line 0 +->0 in file `dbg-cmds.inc' at line 2 +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `dbg-cmds.inc' at line 343 +->2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `dbg-cmds.inc' at line 157 +##3 _Dbg_cmdloop() called from file `dbg-sig.inc' at line 220 +##4 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file `sig.sh' at line 7 +##5 source("sig.sh") called from file `bashdb' at line 277 +##6 main() called from file `bashdb' at line 0 +### Should have printed a stack trace above... +continue ++where +->0 in file `sig.sh' at line 741 +##1 source("sig.sh") called from file `bashdb' at line 277 +##2 main() called from file `bashdb' at line 0 ++continue Program received signal SIGINT (2)... ->0 in file `sig.sh' at line 23 ##1 source("sig.sh") called from file `bashdb' at line 277 @@ -51,9 +61,5 @@ ##1 source("sig.sh") called from file `bashdb' at line 277 ->2 main() called from file `bashdb' at line 0 Debugged program terminated normally. Use q to quit or R to restart. -+where -No stack. -+continue -The program is not being run. +kill sig.tests: line 11: xxxx Killed $BASH ${TOP_BUILDDIR}bashdb -B -q -L .. -x $cmdfile $debugged_script --- /tmp/sig.check2 2016-03-12 17:16:57.000000000 +0800 +++ /tmp/sig.right 2016-03-12 17:16:57.000000000 +0800 @@ -21,6 +21,7 @@ +handle TERM bogus Need to give a command: stop, nostop, stack, nostack, print, noprint +eval kill -TERM $$ +Program received signal SIGTERM (15)... +### Should not have printed a stack trace above... +handle TERM noprint +handle TERM stack @@ -37,11 +38,20 @@ SIGTERM stop noprint showstack trap -- '_Dbg_sig_handler 15 "$BASH_COMMAND" "$@"' SIGTERM +continue Program received signal SIGTERM (15)... -->0 in file `sig.sh' at line 17 -##1 source("sig.sh") called from file `bashdb' at line 277 -->2 main() called from file `bashdb' at line 0 +->0 in file `dbg-cmds.inc' at line 2 +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `dbg-cmds.inc' at line 343 +->2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `dbg-cmds.inc' at line 157 +##3 _Dbg_cmdloop() called from file `dbg-sig.inc' at line 220 +##4 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file `sig.sh' at line 7 +##5 source("sig.sh") called from file `bashdb' at line 277 +##6 main() called from file `bashdb' at line 0 +### Should have printed a stack trace above... +continue ++where +->0 in file `sig.sh' at line 741 +##1 source("sig.sh") called from file `bashdb' at line 277 +##2 main() called from file `bashdb' at line 0 ++continue Program received signal SIGINT (2)... ->0 in file `sig.sh' at line 23 ##1 source("sig.sh") called from file `bashdb' at line 277 @@ -51,9 +61,5 @@ ##1 source("sig.sh") called from file `bashdb' at line 277 ->2 main() called from file `bashdb' at line 0 Debugged program terminated normally. Use q to quit or R to restart. -+where -No stack. -+continue -The program is not being run. +kill sig.tests: line 11: xxxx Killed $BASH ${TOP_BUILDDIR}bashdb -B -q -L .. -x $cmdfile $debugged_script FAIL: run-sig PASS: run-skip checking subshell1... checking subshell2... checking subshell3... PASS: run-subshell PASS: run-tbreak checking trace... checking trace2... PASS: run-trace PASS: run-watch1 PASS: run-watch2 =================================================== 1 of 25 tests failed Please report to bas...@li... =================================================== make[2]: *** [check-TESTS] Error 1 make[2]: Leaving directory `/cpic/sxxsjs/cs1/bashdb-3.1-0.09/test' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/cpic/sxxsjs/cs1/bashdb-3.1-0.09/test' make: *** [check-recursive] Error 1 Best Regards, [logo+纳斯达克邮件.png] 宋若刚 Professional Talent Acquisition Mobile: +86.136.8219.7690 Email: ruo...@pa...<mailto:Jac...@pa...> |
From: Rocky B. <roc...@gm...> - 2015-01-26 16:36:31
|
Looks like debugger doesn't get control when a TERM signal given to the process. This is on cygwin, right? When I this, I get a slightly different difference in line number. But in either case this problem is not serious. I may in the future have this test skipped altogether on cygwin. On Sun, Jan 25, 2015 at 9:54 PM, Frank Ye <Fra...@ca...> wrote: > Got error in both two versions: > bashdb-4.2-0.8/ bashdb-4.3-0.91/ > > > ============================================================================ > Testsuite summary for bashdb 4.3-0.91 > > ============================================================================ > # TOTAL: 42 > # PASS: 38 > # SKIP: 3 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > ============================================================================ > See test/integration/test-suite.log > Please report to bas...@li... > > ============================================================================ > gmake[4]: *** [test-suite.log] Error 1 > gmake[4]: Leaving directory > `/home/frye/scripts/bashdb-4.3-0.91/test/integration' > gmake[3]: *** [check-TESTS] Error 2 > gmake[3]: Leaving directory > `/home/frye/scripts/bashdb-4.3-0.91/test/integration' > gmake[2]: *** [check-am] Error 2 > gmake[2]: Leaving directory > `/home/frye/scripts/bashdb-4.3-0.91/test/integration' > gmake[1]: *** [check-recursive] Error 1 > gmake[1]: Leaving directory `/home/frye/scripts/bashdb-4.3-0.91/test' > gmake: *** [check-recursive] Error 1 > [frye_CPEGA-1808] ... > less test/integration/test-suite.log > ====================================================== > bashdb 4.3-0.91: test/integration/test-suite.log > ====================================================== > > # TOTAL: 42 > # PASS: 38 > # SKIP: 3 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > SKIP: test-file-with-spaces > =========================== > > Skipping test due to autoconf problems > > ====================================================== > bashdb 4.3-0.91: test/integration/test-suite.log > ====================================================== > > # TOTAL: 42 > # PASS: 38 > # SKIP: 3 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > SKIP: test-file-with-spaces > =========================== > > Skipping test due to autoconf problems > > FAIL: test-sig > ============== > > /home/frye/scripts/bashdb-4.3-0.91/test/integration/check-common.sh: line > 26: 9594 Killed $SH -- ${top_builddir}/bashdb $dbg_opts > -x "$cmdfile" "$debugged_script" $ARGS > --- /tmp/sig-filtered.check 2015-01-26 10:53:09.800584240 +0800 > +++ /tmp/sig-filtered.right 2015-01-26 10:53:09.795584240 +0800 > @@ -21,7 +21,7 @@ > +handle TERM bogus > ** Need to give a command: stop, nostop, stack, nostack, print, noprint > +eval kill -TERM $$ > -$? is 0 > +Program received signal SIGTERM (15)... > +### Should not have printed a stack trace above... > +handle TERM noprint > +handle TERM stack > @@ -39,10 +39,15 @@ > SIGTERM stop noprint showstack trap -- '_Dbg_sig_handler 15 > "$BASH_COMMAND" "$@"' SIGTERM > +continue > Program received signal SIGTERM (15)... > -->0 in file `sig.sh' at line 55 > -##1 source("sig.sh") called from file `bashdb' at line 96 > -##2 main() called from file `bashdb' at line 0 > +->0 in file `eval.sh' at line 55 > +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `processor.sh' > at line 293 > +##2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `processor.sh' > at line 202 > +##3 _Dbg_process_commands() called from file `hook.sh' at line 266 > +##4 _Dbg_hook_enter_debugger("after being stepped") called from file > `hook.sh' at line 182 > +##5 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file > `sig.sh' at line 7 > +##6 source("sig.sh") called from file `bashdb' at line 96 > +##7 main() called from file `bashdb' at line 0 > +### Should have printed a stack trace above... > +where 1 > -->0 in file `sig.sh' at line 55 > +->0 in file `eval.sh' at line 55 > > > Frank Ye > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming. The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bashdb-devel mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bashdb-devel > |
From: Frank Ye <Fra...@ca...> - 2015-01-26 03:10:22
|
Got error in both two versions: bashdb-4.2-0.8/ bashdb-4.3-0.91/ ============================================================================ Testsuite summary for bashdb 4.3-0.91 ============================================================================ # TOTAL: 42 # PASS: 38 # SKIP: 3 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See test/integration/test-suite.log Please report to bas...@li... ============================================================================ gmake[4]: *** [test-suite.log] Error 1 gmake[4]: Leaving directory `/home/frye/scripts/bashdb-4.3-0.91/test/integration' gmake[3]: *** [check-TESTS] Error 2 gmake[3]: Leaving directory `/home/frye/scripts/bashdb-4.3-0.91/test/integration' gmake[2]: *** [check-am] Error 2 gmake[2]: Leaving directory `/home/frye/scripts/bashdb-4.3-0.91/test/integration' gmake[1]: *** [check-recursive] Error 1 gmake[1]: Leaving directory `/home/frye/scripts/bashdb-4.3-0.91/test' gmake: *** [check-recursive] Error 1 [frye_CPEGA-1808] ... > less test/integration/test-suite.log ====================================================== bashdb 4.3-0.91: test/integration/test-suite.log ====================================================== # TOTAL: 42 # PASS: 38 # SKIP: 3 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 SKIP: test-file-with-spaces =========================== Skipping test due to autoconf problems ====================================================== bashdb 4.3-0.91: test/integration/test-suite.log ====================================================== # TOTAL: 42 # PASS: 38 # SKIP: 3 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 SKIP: test-file-with-spaces =========================== Skipping test due to autoconf problems FAIL: test-sig ============== /home/frye/scripts/bashdb-4.3-0.91/test/integration/check-common.sh: line 26: 9594 Killed $SH -- ${top_builddir}/bashdb $dbg_opts -x "$cmdfile" "$debugged_script" $ARGS --- /tmp/sig-filtered.check 2015-01-26 10:53:09.800584240 +0800 +++ /tmp/sig-filtered.right 2015-01-26 10:53:09.795584240 +0800 @@ -21,7 +21,7 @@ +handle TERM bogus ** Need to give a command: stop, nostop, stack, nostack, print, noprint +eval kill -TERM $$ -$? is 0 +Program received signal SIGTERM (15)... +### Should not have printed a stack trace above... +handle TERM noprint +handle TERM stack @@ -39,10 +39,15 @@ SIGTERM stop noprint showstack trap -- '_Dbg_sig_handler 15 "$BASH_COMMAND" "$@"' SIGTERM +continue Program received signal SIGTERM (15)... -->0 in file `sig.sh' at line 55 -##1 source("sig.sh") called from file `bashdb' at line 96 -##2 main() called from file `bashdb' at line 0 +->0 in file `eval.sh' at line 55 +##1 _Dbg_do_eval("kill", "-TERM", "$$") called from file `processor.sh' at line 293 +##2 _Dbg_onecmd("eval", "kill -TERM $$") called from file `processor.sh' at line 202 +##3 _Dbg_process_commands() called from file `hook.sh' at line 266 +##4 _Dbg_hook_enter_debugger("after being stepped") called from file `hook.sh' at line 182 +##5 _Dbg_debug_trap_handler("0", "[[ "$1"x != x ]]") called from file `sig.sh' at line 7 +##6 source("sig.sh") called from file `bashdb' at line 96 +##7 main() called from file `bashdb' at line 0 +### Should have printed a stack trace above... +where 1 -->0 in file `sig.sh' at line 55 +->0 in file `eval.sh' at line 55 Frank Ye |