bugGNU Octave - Bugs: bug #65277, run_test_suite in Octave 9.0.90...

 
 

bug #65277: run_test_suite in Octave 9.0.90 throws "error: get_breakpoint_list: . .."

Submitter:  Hartmut <hardy>
Submitted:  Thu 08 Feb 2024 08:33:39 PM UTC
   
 
Category:  Test Suite Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 9.0.90 Operating System:  * Any
Fixed Release:  9.1.0 Planned Release:  9.1.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 21 Feb 2024 05:06:49 PM UTC, comment #28: 

If the original issue is resolved, can we close this bug report?  I agree with Markus that it can be confusing if the discussion has now moved on to a different problem.

Rik <rik5>
Group administrator
Wed 14 Feb 2024 04:40:55 PM UTC, comment #27: 


comment #26:

> It sounds like three different issues are discussed in this report by now:


> Discussing many different issues in the same report can get pretty confusing imho. Could you please open dedicated reports for the issues you are seeing?



See https://savannah.gnu.org/bugs/?65312

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 08:10:27 AM UTC, comment #26: 

It sounds like three different issues are discussed in this report by now:
1. Hartmut's original issue (which is resolved now iiuc)
2. The issue that jwe and Torsten are describing sounds very similar and might be the same.
3. The issue that Dmitri is describing sounds quite different from issue 2.

(Neither issue 2 nor 3 reproduce for me here on Windows 11.)

Discussing many different issues in the same report can get pretty confusing imho. Could you please open dedicated reports for the issues you are seeing?
(For both problems: Does switching the setting for native file dialogs (on the "General" tab of the "Preferences" dialog) make a difference? ISTR that they caused a wide range of different symptoms for some users in the past.)

Markus Mützel <mmuetzel>
Group administrator
Wed 14 Feb 2024 03:04:53 AM UTC, comment #25: 

Here is what I see while attached to hange octave process:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00007fa5ce43bd27 in __GI___wait4 (pid=319860, stat_loc=0x7ffd79cd5f60, options=0, usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
30        return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
(gdb) where
#0  0x00007fa5ce43bd27 in __GI___wait4 (pid=319860, stat_loc=0x7ffd79cd5f60, options=0, usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x00007fa5ce43be6b in __GI___waitpid (pid=<optimized out>, stat_loc=<optimized out>, options=<optimized out>) at waitpid.c:38
#2  0x00000000004044e0 in octave_waitpid_wrapper (pid=<optimized out>, statusp=<optimized out>, options=<optimized out>)
    at ../liboctave/wrappers/wait-wrappers.c:101
#3  0x00000000004033e8 in main (argc=2, argv=0x7ffd79cd6178) at src/main.cc:525
(gdb) list
25      pid_t
26      __wait4_time64 (pid_t pid, int *stat_loc, int options, struct __rusage64 *usage)
27      {
28      #ifdef __NR_wait4
29      # if __KERNEL_OLD_TIMEVAL_MATCHES_TIMEVAL64
30        return SYSCALL_CANCEL (wait4, pid, stat_loc, options, usage);
31      # else
32        pid_t ret;
33        struct __rusage32 usage32;
34
(gdb) thread apply all bt

Thread 1 (Thread 0x7fa5ce8737c0 (LWP 319859) "octave"):
#0  0x00007fa5ce43bd27 in __GI___wait4 (pid=319860, stat_loc=0x7ffd79cd5f60, options=0, usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x00007fa5ce43be6b in __GI___waitpid (pid=<optimized out>, stat_loc=<optimized out>, options=<optimized out>) at waitpid.c:38
#2  0x00000000004044e0 in octave_waitpid_wrapper (pid=<optimized out>, statusp=<optimized out>, options=<optimized out>) at ../liboctave/wrappers/wait-wrappers.c:101
#3  0x00000000004033e8 in main (argc=2, argv=0x7ffd79cd6178) at src/main.cc:525
(gdb)


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 02:30:22 AM UTC, comment #24: 

Here is a strace output (str2.log.gz , attached).

I guess I could also run under gdb, but would not know what to do there.

Dmitri.
--


(file #55693)

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 01:40:43 AM UTC, comment #23: 


comment #21:

>
> The first step might be to try to find out what is actually being executed while Octave is taking a long time to execute a particular test.  I'll see if I can find something.


https://www.amd.com/en/developer/uprof.html

might be helpful.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 01:35:08 AM UTC, comment #22: 

Bizarre. For me in the experimental widget it runs as well as in CLI.
Do you get Glib-GIO-Critical warnings?
I have noticed that the deluge of those warnings go to "normal" command window but stay in the xterminal where I started the octave when I use the experimental widget. I thought that there is may be some kind of contention between octave thread and Glib process writing to the same place and that is causing the hangup.

As I mentioned elsewhere, the command windows freezes first (stops updating) while octave continues through some more tests
until it finally hangs up (judging by the output in fntests.log).

This is with either 8.4.0 (provided by repo, compiled with Qt5) or with 9.0.91 (compiled with either Qt5 or Qt6).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Wed 14 Feb 2024 01:15:34 AM UTC, comment #21: 

I tried building dc69e574b97a with Qt6 and running with --experimental-terminal-widget and it still hangs for me so I don't think it is the terminal widget that is causing the trouble.  I see it taking 58 seconds to execute the tests in dirfns.cc-tst.  It continues, but has more problems later.  98 seconds in dlmread.cc-tst and 62 seconds in dot.cc-tst.  At first I thought maybe it was filesystem related, but the doc.c-tst file doesn't seem to do anything with functions that look at the filesystem.  And running "test dot.cc-tst" by itself works fine.

I also tried going back to the point where we first made it possible to build with Qt6.  I wasn't sure what revision to use as we had to fix a lot of things to get Octave to build with Qt6.  I had some trouble with the very early revisions that attempted to support Qt6 but building de6e2f546970 worked for me and it appears to have the same trouble executing _run_test_suite_.  So debugging this may take some work as we don't have an obvious small change that caused the problem.

The first step might be to try to find out what is actually being executed while Octave is taking a long time to execute a particular test.  I'll see if I can find something.

John W. Eaton <jwe>
Group administrator
Tue 13 Feb 2024 09:26:03 PM UTC, comment #20: 


comment #19:

> I make similar observations to what jwe reports in comment #16. _run_test_suite_ is very slow in the GUI.
>
> * _run_test_suite_ in CLI:   7:20
> * _run_test_suite_ in GUI:  44:25 (mappers.cc took over 200s!)
>
> Maybe related, when "save & run" an editor file, it takes a very long time (approx. 5s) until the related command is shown in the command widget and the script is actually processed.


Try it in `--experimental-terminal-widget`.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 13 Feb 2024 09:05:32 PM UTC, comment #19: 

I make similar observations to what jwe reports in comment #16. _run_test_suite_ is very slow in the GUI.

  • _run_test_suite_ in CLI:   7:20
  • _run_test_suite_ in GUI:  44:25 (mappers.cc took over 200s!)


Maybe related, when "save & run" an editor file, it takes a very long time (approx. 5s) until the related command is shown in the command widget and the script is actually processed.

Torsten Lilge <ttl>
Group Member
Tue 13 Feb 2024 07:01:19 PM UTC, comment #18: 


comment #16:

>
> Also, even though I'm seeing the problem with Qt6 and not with Qt5, it's not clear whether this is a bug in Qt (possible) or just something we are doing wrong (seems at least as likely)
>



On current Fedora 39. _run_test_suite_ hangs GUI 100% reproducibly on 3 different computers I have tried (AMD 8350, Ryzen 3950, Raspberry PI aarch64), provided it started in Gnome/GTK environment. It happens with both Qt5 and Qt6 and goes as far back as 8.4.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 13 Feb 2024 06:14:21 PM UTC, comment #17: 

I have now

  • applied Markus' patch from comment #12
  • ticked the GUI preference dialog again back to "Always show debug breakpoints and pointers (opens related files if closed)" = ON
  • run "__run_test_suite__" on the same PC as I reported the original issue in comment #0 with, still in GUI Octave


and as a result all the "error: get_breakpoint_list:..." errors are still gone. I see:


Summary:

  PASS                            18734
  FAIL                                0
  XFAIL (reported bug)               37
  SKIP (missing feature)             22
  SKIP (run-time condition)          29

See the file /home/hartmut/fntests.log for additional details.

XFAIL items are known bugs or expected failures.
Bug report numbers may be found in the log file:
/home/hartmut/fntests.log
Please help improve Octave by contributing fixes for them.

Tests are often skipped because required features were
disabled or were not present when Octave was built.
The configure script should have printed a summary
indicating which dependencies were not found.

130 (of 898) .m files have no tests.

Please help improve Octave by contributing tests for these files
(see the list in the file /home/hartmut/fntests.log).

>>


So I would conclude, that Markus' patch from comment #12 solves my originally reported issue fully.

What still remains, is probalby John's new observation in comment #16.

Hartmut <hardy>
Tue 13 Feb 2024 05:35:40 PM UTC, comment #16: 

Executing _run_test_suite_ in the GUI with 8.4.0 works regardless of the setting for opening files in the editor to display breakpoints.  My 8.4.0 build uses Qt5.

Using revision bf0b6e629eff (the parent of Markus' recent changeset that disables the file-opening preference when running some tests) I see some strange behavior but only with Qt6.

With Qt5, it works the same as my 8.4.0 build.  Either debug breakpoint display setting works and _run_test_suite_ finishes in a reasonable time.

With Qt6, _run_test_suite_ is quite slow and sometimes the process appears to hang, with Gnome reporting that octave-gui is is not responding and asking whether to kill it.  I'm seeing this behavior with a normal build, not with the thread sanitizer enabled (which I believe may slow execution).  It also happens with the breakpoint display setting disabled.

Also, even though I'm seeing the problem with Qt6 and not with Qt5, it's not clear whether this is a bug in Qt (possible) or just something we are doing wrong (seems at least as likely)

I tried removing the ~/.config/octave and ~/.local/share/octave directories and there was no change in behavior for me.

John W. Eaton <jwe>
Group administrator
Mon 12 Feb 2024 10:07:37 PM UTC, comment #15: 

So far I have (only) tested Markus' suggestion in comment #11 (de-activating the preference-setting to open debug-point related files, manually). After running the _run_test_suite_ inside GUI Octave, I then see the following:


Summary:

  PASS                            18734
  FAIL                                0
  XFAIL (reported bug)               37
  SKIP (missing feature)             22
  SKIP (run-time condition)          29

See the file /home/hartmut/fntests.log for additional details.

XFAIL items are known bugs or expected failures.
Bug report numbers may be found in the log file:
/home/hartmut/fntests.log
Please help improve Octave by contributing fixes for them.

Tests are often skipped because required features were
disabled or were not present when Octave was built.
The configure script should have printed a summary
indicating which dependencies were not found.

130 (of 898) .m files have no tests.

Please help improve Octave by contributing tests for these files
(see the list in the file /home/hartmut/fntests.log).

>>


My conclusion would be: Yes, deactivating this GUI editor setting does fully solve this issue. Good guess, Markus!

Also, no m-files at all are open after running _run_test_suite_, this way.

(I will only be able to also test Markus' patch from comment #12 some time later, hopefully tomorrow.)

Hartmut <hardy>
Mon 12 Feb 2024 08:42:39 PM UTC, comment #14: 

I removed ~/.config/octave and ~/.local/share/octave
and now the files are not opened after the _run_test_suite_

Dmitri.
--


Dmitri A. Sergatskov <dasergatskov>
Mon 12 Feb 2024 07:39:36 PM UTC, comment #13: 

I do not see any difference -- on the systems where the files were opening, they are still being opened.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 12 Feb 2024 05:05:40 PM UTC, comment #12: 

I pushed the following change to avoid having the GUI open files in the built-in editor when adding breakpoints during the test suite:
https://hg.savannah.gnu.org/hgweb/octave/rev/175eb207d9d9

These are two less files that should be opening in the built-in editor compared to the previous changeset. And you were seeing two error messages.
Do you still see them after these changes?

Markus Mützel <mmuetzel>
Group administrator
Mon 12 Feb 2024 01:17:42 PM UTC, comment #11: 

The changeset combined some steps from three different tests into one single test. So, the total test count should be lower by 2.
That probably means that you correctly applied the patch.

I wonder why you still see those errors. If this is failing because of what I thought, there should be no errors like that at all. If the errors happen for a different reason, the number of errors shouldn't have changed.

`__run_test_suite__` in the GUI, doesn't emit those errors for me here. But if this is a threading issue, it might be easier to reproduce on some systems than on others.

I can confirm however that `help.m`, `ls.m`, and `classdef_breakpoints.m` open in the built-in editor while running the test suite (and stay open when it is done). `classdef_breakpoints.m` no longer opens after the changes from comment #9. So, maybe we'll need similar changes to the tests that open the other two files.

CC'ing Torsten because I hope he better understands how the built-in editor interacts with breakpoints if `editor/show_dbg_file` is set to "true".

@Hartmut: Do you still see this error if you de-activate the checkbox next to "Always show debug breakpoints and pointers (opens related files if closed)" on the "Editor" panel of the preferences?

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Feb 2024 07:18:44 PM UTC, comment #10: 

I have applied Markus' the patch from comment #9. Then I run "__run_test_suite__" from within the Octave GUI (having my octaverc file renamed before). As a result I do see an improvement, I now only get two of those error messages, not three error messages as before. On the other side, I have two tests less that "pass". It looks like this in my GUI console (compare to my comment #0):

Summary:

  PASS                            18734
  FAIL                                0
  XFAIL (reported bug)               37
  SKIP (missing feature)             22
  SKIP (run-time condition)          29

See the file /home/hartmut/fntests.log for additional details.

XFAIL items are known bugs or expected failures.
Bug report numbers may be found in the log file:
/home/hartmut/fntests.log
Please help improve Octave by contributing fixes for them.

Tests are often skipped because required features were
disabled or were not present when Octave was built.
The configure script should have printed a summary
indicating which dependencies were not found.

130 (of 898) .m files have no tests.

Please help improve Octave by contributing tests for these files
(see the list in the file /home/hartmut/fntests.log).

>> error: get_breakpoint_list: unable to find function '@classdef_breakpoints/bar'
>> error: get_breakpoint_list: unable to find function '@classdef_breakpoints/bar'
>>


I cannot judge if this behavior is worth the effort.

(I hope I applied the patch correctly: I simply extracted the file "test_classdef_breakpoints.tst" from another local repository after applying this patch file. Then I copied this tst file into the corresponding folder in my Octave 9.0.90 installation and re-run "make" and "make install". If this was not the right way of doing it, please let me know.)

Hartmut <hardy>
Fri 09 Feb 2024 05:22:47 PM UTC, comment #9: 

Imho, we should try to make the test suite resilient against these kinds of errors if possible.

If I understand correctly, the GUI tries to queue commands that open the respective file in the built-in editor. But it might happen that the current folder already changed when the commands in the queue get to be executed. In that case, the file from the test case can no longer be found and the error message occurs.

Does the attached patch avoid those error messages from the GUI during `__run_test_suite__` for you?


(file #55680)

Markus Mützel <mmuetzel>
Group administrator
Fri 09 Feb 2024 04:42:46 PM UTC, comment #8: 


> as response to Rik's comment #4:

Running this very command starts octave-cli, and in the CLI I do NOT see these three strange warnings (see my comment #3).

Just to be clear, "octave-cli" is different from "octave --no-gui".  The former does not have Qt libraries linked in, while the latter binary has them linked in but the GUI is not started.

If the following commands work on all machines


octave -f
__run_test_suite__


then I would vote to ignore warnings/errors in the GUI and only run the test suite with the --no-gui option (which is implicit).

Rik <rik5>
Group administrator
Fri 09 Feb 2024 04:38:41 PM UTC, comment #7: 

I think _run_test_suite_ may be problematic when run in the GUI.  I don't use the GUI much, but I seem to recall that there are automatic options when setting a breakpoint to open the file in the editor and display the line where the breakpoint occurs.  The '-f' command-line option to start Octave prevents reading initialization files like .octaverc, but it doesn't prevent the GUI from reading the user's configuration file as far as I know.  There could be personal settings there that interact with the test suite.

I think the easiest thing to verify that Octave is working on a particular platform would be to run it without starting the GUI.  Seems like a lot of developer hours could be spent trying to track down this issue, when there is already a solution.





Rik <rik5>
Group administrator
Fri 09 Feb 2024 07:14:16 AM UTC, comment #6: 

as response to Rik's comment #4:

  • Running this very command starts octave-cli, and in the CLI I do NOT see these three strange warnings (see my comment #3).
  • When I instead start Octave the following way, instead:


./octave -f --gui
__run_test_suite__

Then I do see the three breakpoint errors as shown in my comment #0

My computer used has a Ubuntu "20.04.6 LTS" linux.

On my computer, after running the test suite inside Octave GUI, I also have the three m-files open in the editor, as described by Dmitri in comment #5. (Having m-files open after run_test_suite is the same as with older Octave versions, when I remember correctly. Just the open "classdef_breakpoints.m" seems to be new.)

Hartmut <hardy>
Fri 09 Feb 2024 12:50:40 AM UTC, comment #5: 

On Ubuntu 23.10 and windows after _run_test_suite_ (in gui) I have 3 files open in the Editor: help.m, ls.m, classdef_breakpoints.m

This does not happen on Centos for some reason (?!)

I also do not see the error messages in all my computers I tried so far.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 08 Feb 2024 11:58:23 PM UTC, comment #4: 

For what it's worth, I don't get these messages on a generic Kubuntu 22.04 machine.  But, this could be a race condition that is heavily dependent on actual hardware timings.

Could you try starting octave as


octave -f
__run_test_suite__


which will not read any initialization files (user-specific or system-wide).


Rik <rik5>
Group administrator
Thu 08 Feb 2024 10:32:27 PM UTC, comment #3: 

I have just run "__run_test_suite__" from within octave-cli and do NOT see these error messages then.

Hartmut <hardy>
Thu 08 Feb 2024 10:28:17 PM UTC, comment #2: 

Yes, I've also done "make install", and installed the Octave binaries into a subfolder in "/opt". I then use the binaries in this subfolder.

I only used the GUI version of Octave (never the CLI version, so far).

I have seen these error messages when starting the Octave GUI via "run-octave" from within this Octave folder, but also when starting the Octave GUI (via a .desktop shortcut) with "/opt/octave-9.0.90/bin/octave --gui %f".

Hartmut <hardy>
Thu 08 Feb 2024 10:19:48 PM UTC, comment #1: 

Have you run 'make install' and are then running the resulting binary which might be in /usr/local/bin or similar?  Or are you using the 'run-octave' script in the build directory?

Similarly, are you running the CLI version of Octave (octave-cli executable) and getting these errors or the version of Octave with GUI libraries linked in (octave executable).

And do you invoke Octave with any command-line arguments such as "--gui" or "-f"?

Rik <rik5>
Group administrator
Thu 08 Feb 2024 08:33:39 PM UTC, original submission:  

I installed the 9.0.90 tar-file (from the official alpha.gnu.org server) on my Ubuntu linux. "make check" returned 0 fails, and under the GUI also run_test_suite also returned 0 fails. But when running "__run_test_suite__" I reproducibly see three unexpected errors in the console output:


Summary:

  PASS                            18736
  FAIL                                0
  XFAIL (reported bug)               37
  SKIP (missing feature)             22
  SKIP (run-time condition)          29

See the file /opt/octave-9.0.90/fntests.log for additional details.

XFAIL items are known bugs or expected failures.
Bug report numbers may be found in the log file:
/opt/octave-9.0.90/fntests.log
Please help improve Octave by contributing fixes for them.

Tests are often skipped because required features were
disabled or were not present when Octave was built.
The configure script should have printed a summary
indicating which dependencies were not found.

130 (of 898) .m files have no tests.

Please help improve Octave by contributing tests for these files
(see the list in the file /opt/octave-9.0.90/fntests.log).

>> error: get_breakpoint_list: unable to find function '@classdef_breakpoints/bar'
>> error: get_breakpoint_list: unable to find function '@classdef_breakpoints/bar'
>> error: get_breakpoint_list: unable to find function '@classdef_breakpoints/bar'
>>


I am unsure if this is a problem. But since I could not find an existing bug report in savannah for this, I just report it here.

If you need further information on my PC or my Octave 9.0.90 installation, then please let me know.

Hartmut <hardy>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #55693:  str2.log.gz added by dasergatskov (3KiB - application/gzip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel
  • -email is unavailable- added by mmuetzel (Updated the item)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-03-03 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 9.1.0
    2024-02-14 dasergatskov Attached File- Added str2.log.gz, #55693
    2024-02-12 mmuetzel StatusPatch Submitted Ready For Test
        Operating SystemGNU/Linux Any
        Planned ReleaseNone 9.1.0
    2024-02-12 mmuetzel Carbon-Copy- Added ttl
    2024-02-09 mmuetzel Attached File- Added bug65277-test-classdef-dbstop.patch, #55680
        StatusNeed Info Patch Submitted
    2024-02-08 rik5 CategoryNone Test Suite
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code