bugGNU Octave - Bugs: bug #56097, unlink ("filename")...

 
 

bug #56097: unlink ("filename") hangs GUI

Submitter:  Dieter Kadelka <dkadelka>
Submitted:  Mon 08 Apr 2019 10:32:07 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 5.1.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 11 Apr 2019 05:56:11 PM UTC, comment #38: 

Sure, send the discussion over to the Maintainer's List and I'll close this report.

I agree that either method, compile-time or run-time, produces code that can be hard to follow.  With the run-time method, I feel like I'm back programming in C and having to defensively check pointer validity all the time.

If we do opt to make the Editor Window valid at all times then we can either skip fixing bug #56114 (gray out menu entries when Editor not present), or fall back on a compile-time test.  My vote would still be to gray the entries out because I find it a non-intuitive UI that lets me click on things only to tell me afterwards that it is unavailable.  Better, in my mind, to give those cues to the user earlier.

Closing this report.

 Rik <rik5>
Group administrator
Thu 11 Apr 2019 04:56:10 PM UTC, comment #37: 

I don't see performance as an issue here.  More important to me is avoiding these kinds of errors in the future.

Whether we use #ifdef or run-time conditionals, they are not a great solution because in all places where it is used, we have to remember to check that m_editor_window is valid.  This requirement is not shared by other objects and I don't think we want to clutter the code with unnecessary checks on pointers that we know will always be valid for the life of the object.  Because most objects are always valid, it is easy to forget to check the ones that might be NULL.

Another option is to always create the editor window object so, like other sub-window objects contained in the main_window object, it can be assumed to exist.  If the editor window doesn't actually provide an editor, it could just be a text a text widget that displays the message "To provide a functional built-in editor, Octave requires QScintilla."

Maybe we should adopt this approach as a coding guideline for the GUI so that we avoid the confusion of having some objects that can be invalid.

We recently had another similar bug with dereferencing a NULL pointer when the help engine is not available (bug #55736).  It seems to me that our code would be more reliable if, instead of having to protect m_help_engine (or m_editor_window) with #ifdefs or run-time conditions, we ensured that these objects were always valid.  It would also be nice if we could use references for them (by definition they are always valid) but I don't think Qt allows us to do that.

This bug report is kind of an obscure place to have this discussion, so maybe we should move it to the mailing list?

 John W. Eaton <jwe>
Group administrator
Thu 11 Apr 2019 04:03:46 PM UTC, comment #36: 

@jwe: Your solution would future proof Octave if another editor is ever added.  On the negative side, it substitutes a compile-time test with a run-time test so there are potential performance concerns.  I don't know whether this is a legitamate concern or not since the GUI operates at human time scales which are pretty slow.

If we wanted to preserve the compile-time test then we could change the code to use a more generic conditional such as HAVE_GUI_EDITOR and then in configure.ac there could be a single line


#define HAVE_GUI_EDITOR (HAVE_QSCINTILLA || HAVE_OTHER_EDITOR1 || HAVE_OTHER_EDITOR2)


I did not close this report since there is this remaining question open about future proofing the code.  Changes for this issue should be made on the development branch, not the stable branch.

Rik <rik5>
Group administrator
Thu 11 Apr 2019 03:56:54 PM UTC, comment #35: 

@Torsten: The patch works well.

This is a problem for the stable branch as well as the development branch so I backported the patch to stable here (https://hg.savannah.gnu.org/hgweb/octave/rev/32d9f57d7245).

The reason it took so long to uncover this issue is that we do not have a full regression test suite which covers all of the C++ files.  So this doesn't happen again for this particular function I added BIST tests for unlink here https://hg.savannah.gnu.org/hgweb/octave/rev/8c4f01b66c0b.

With the new patch in place there was a warning about unused parameters during compilation so I added some extra code in a #else branch of #ifdef (HAVE_QSCINTILLA) that silences that.  See https://hg.savannah.gnu.org/hgweb/octave/rev/6caf75200854.

Marking this bug as fixed.

 Rik <rik5>
Group administrator
Thu 11 Apr 2019 08:17:36 AM UTC, comment #34: 

Thanks, that fixes the problem for me as well when I configure without qscintilla.

I would like to also propose the following patch since in the future we may have an editor window that does not use qscintalla.



(file #46744)

 John W. Eaton <jwe>
Group administrator
Thu 11 Apr 2019 05:30:55 AM UTC, comment #33: 

Changeset http://hg.savannah.gnu.org/hgweb/octave/rev/43f6f02dd91c fixes the issue for me with a build configured without qscintilla.

 Torsten Lilge <ttl>
Group Member
Wed 10 Apr 2019 08:36:50 PM UTC, comment #32: 

Rik, Dieter, thanks for testing.

The hint to wait () in octave-qt-link was helpful. I will also reconfigure my build and hope to nail this down.

 Torsten Lilge <ttl>
Group Member
Wed 10 Apr 2019 05:11:52 PM UTC, comment #31: 

Reply to Comment #23:
Hello Torsten. I applied the patch. Unfortunately this has no effect.
I will wait for Leap 15.1. I think then I will have a better QScintilla with development tools. I tried to install QScintilla locally. No chance. I don't have qmake.

Comment #30: Is there an option in configure to enclose debug information for gdb? I don't see any possibility.

 Dieter Kadelka <dkadelka>
Wed 10 Apr 2019 04:46:55 PM UTC, comment #30: 

I used gdb to step through the code.  The hang is happening in libgui/src/octave-qt-link.cc.  The code is below


void octave_qt_link::do_file_remove (const std::string& old_name,
                                     const std::string& new_name)
{
  // Lock the mutex before signaling
  lock ();

  // Emit the signal for the editor for closing the file if it is open
  emit file_remove_signal (QString::fromStdString (old_name),
                           QString::fromStdString (new_name));

  // Wait for the GUI and unlock when resumed
  wait ();
  unlock ();
}


The code executes up until the call to wait() and then hangs.  I don't know enough about how signals operate in the GUI to say any more.



Rik <rik5>
Group administrator
Wed 10 Apr 2019 04:43:04 PM UTC, comment #29: 

@Ka;: Unfortunately, Octave still hangs with the patch applied.  This is probably on the right track, but there must be more to it.

I'm also going to file a minor bug about the Window menu when Qscintilla is disabled.  The menu still has a clickable item for showing the Editor window, and for switching to the Editor window.  Neither of these options will work without Qscintilla so they should be grayed out.

 Rik <rik5>
Group administrator
Wed 10 Apr 2019 03:50:43 PM UTC, comment #28: 

@Dieter: Sorry that this borked your system.

On the positive side, with Kai's hint I re-configured the build with the '--without-qscintilla' option.  After building, I can confirm the hang that Dieter is experiencing.  I'm going to try the patch now and see if it resolves the issue.

 Rik <rik5>
Group administrator
Wed 10 Apr 2019 11:07:41 AM UTC, comment #27: 

Regarding comment #25,

I think my system is not quite stable. Unfortunately I installed coreutils from with prefix=/usr and not with prefix=/usr/local, as recommended. I don't know why.

I reinstalled coreutils from Leap 15.0 and will install octave-5.1.0 anew. If this doesn't work I will apply the patch.

Thank you Kai

 Dieter Kadelka <dkadelka>
Wed 10 Apr 2019 10:01:04 AM UTC, comment #26: 

Regarding comment #25: I see the problem :(

I think solving this is not interesting for this bug tracker.  You can write me (in German if you like) a personal message or by email (k.ohlhus@gmail.com).  Short version is: get in YAST rid of the additional KDE (and maybe other) repository. It is mainly for development, and partially unstable (I do not use it)  https://en.opensuse.org/SDB:Add_package_repositories . Finally run


sudo zypper dist-upgrade


to get the stable state of all KDE packages back again.

 Kai Torben Ohlhus <siko1056>
Group Member
Wed 10 Apr 2019 09:28:13 AM UTC, comment #25: 

Answer Comment #22
Hello Kai,

Yesterday I tried to install a new version of libqscintilla_qt5 and crashed my system. All of kde, much of qt and configuration got lost. Unfortunately this is no option for me. I think I have a broken Leap 15.0 which is running quite good anyway.

Never change a running system.

Here is part of my problem:

zypper in libqscintilla_qt5-devel
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...

Problem: libqscintilla_qt5-devel-2.11.1-lp150.37.1.x86_64 benötigt libQt5Core.so.5(Qt_5.12)(64bit), kann jedoch nicht zur Verfügung gestellt werden
  Nicht installierbare Anbieter: libQt5Core5-5.12.2-lp150.1.1.x86_64[openSUSE_Leap_15.0]
 Lösung 1: Folgende Aktionen werden ausgeführt:
  libQt5Core5-5.12.2-lp150.1.1.x86_64 installieren (mit Anbieterwechsel)
    openSUSE --> obs://build.opensuse.org/KDE
  libQt5Location5-5.12.2-lp150.1.1.x86_64 installieren (mit Anbieterwechsel)
    openSUSE --> obs://build.opensuse.org/KDE
  libQt5Multimedia5-5.12.2-lp150.1.1.x86_64 installieren (mit Anbieterwechsel)
    openSUSE --> obs://build.opensuse.org/KDE
  libQt5NetworkAuth5-5.12.2-lp150.1.1.x86_64 installieren (mit Anbieterwechsel)
    openSUSE --> obs://build.opensuse.org/KDE
  libQt5Positioning5-5.12.2-lp150.1.1.x86_64 installieren (mit Anbieterwechsel)
    openSUSE --> obs://build.opensuse.org/KDE
  libQt5QuickControls2-5-5.12.2-lp150.3.2.x86_64 installieren (mit Anbieterwechsel)
    openSUSE --> obs://build.opensuse.org/KDE

and much more

I have

libqscintilla2_qt5-13 - C++ Editor Class Library (2.19.4-lp150-1.13)

installed. There are no development files (at least in Suse) available.

 Dieter Kadelka <dkadelka>
Wed 10 Apr 2019 09:03:28 AM UTC, comment #24: 

Answer to #20
Hello Rik, I get

0000000000dca880 T octave_unlink_wrapper
                 U unlink@@GLIBC_2.2.5
0000000000d83050 T _ZN6octave3sys6unlinkERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
00000000002e97cd t _ZN6octave3sys6unlinkERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE.cold.61
0000000000d82ff0 T ZN6octave3sys6unlinkERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERS6
0000000000d828a0 t ZN6octave3sys6unlinkERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERS6.part.20


Dieter Kadelka <dkadelka>
Wed 10 Apr 2019 04:39:59 AM UTC, comment #23: 

There is a bug in the auto-close code for removed files. It only shows up when the editor is not available. However, I merely would expect a crash than a hang of the gui.

Could you please test the attached patch if building again without qscintilla?

(file #46743)

 Torsten Lilge <ttl>
Group Member
Wed 10 Apr 2019 04:21:59 AM UTC, comment #22: 

Sorry for coming late to this discussion.  I am running Octave 4.4.1, 5.1.0, and 6.0 on openSUSE Leap 15.0 without any trouble like described by the OP.

Regarding comment #19.  Try to build with the official qscintilla development package:


$ sudo zypper info libqscintilla_qt5-devel
Loading repository data...
Reading installed packages...


Information for package libqscintilla_qt5-devel:
------------------------------------------------
Repository     : openSUSE-Leap-15.0-Oss
Name           : libqscintilla_qt5-devel
Version        : 2.10.4-lp150.1.13
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 460.8 KiB
Installed      : Yes
Status         : up-to-date
Source package : qscintilla-qt5-2.10.4-lp150.1.13.src
Summary        : C++ Editor Class Library Development Files
Description    :
    QScintilla is a Qt port of Neil Hodgson's Scintilla C++ editor class.

    This is a Qt port from the original Scintilla class
    (http://www.scintilla.org/).

    This package contains the development files for qscintilla-qt5.


I think we can easily close this bug, by properly setting up your openSUSE Leap 15.0.  Please install all of

https://build.opensuse.org/package/view_file/science/octave/octave.spec?expand=1  (see the "BuildRequires" library names).

build again and see, if the problems are still present.

 Kai Torben Ohlhus <siko1056>
Group Member
Tue 09 Apr 2019 11:06:01 PM UTC, comment #21: 

Unfortunately I crashed my system. kde is not working any longer. I have to restore before I can answer.

 Dieter Kadelka <dkadelka>
Tue 09 Apr 2019 09:55:51 PM UTC, comment #20: 

I doubt it's a problem with perl, but of course check to see.

In Octave, unlink is C++ code which calls a wrapper function around C code.  If the operating sysem implements unlink correctly then the call is forwarded to the OS, otherwise gnulib substitutes C code for an implementation that works.

You can check by running the following from the top-level directory where you built Octave


nm liboctave/.libs/liboctave.so | grep unlink


On my system, I got


0000000000e2b750 T octave_unlink_wrapper
                 U unlink@@GLIBC_2.2.5


so GNU libc is the ultimate provider of the unlink function for me.


Rik <rik5>
Group administrator
Tue 09 Apr 2019 09:14:45 PM UTC, comment #19: 

I'm building without libqscintilla. Leap 15.0 has no development files for libqscintilla.

 Dieter Kadelka <dkadelka>
Tue 09 Apr 2019 06:31:57 PM UTC, comment #18: 

Okay, since unlink hangs the GUI even without any other actions involved (no previously invoked help and started with -f option) this is no dead-lock between worker thread and GUI.

Are you building with or without libqscintilla?

 Torsten Lilge <ttl>
Group Member
Tue 09 Apr 2019 05:24:42 PM UTC, comment #17: 

In addition, there may be a problem with my local version of perl. Maybe its not compatible with Leap 15.0. perl contains the script unlink.

Later I will try to uninstall my local version of perl and see if it has any effect.

 Dieter Kadelka <dkadelka>
Tue 09 Apr 2019 05:10:07 PM UTC, comment #16: 

As expected octave hangs after unlink ("abc")

1. I have Suse Leap 15.0 with many tools added in /usr/local (almost all installed by tar balls)
   There are not enough tools in Leap 15.0
2. My system is not hardened
3. gcc (GCC) 8.3.0 and /lib/libc-2.26.so
4. I built from tar ball octave-5.1.0.tar.gz
5. No options. I did ./configure ; make ; make install

 Dieter Kadelka <dkadelka>
Tue 09 Apr 2019 03:46:56 PM UTC, comment #15: 

All of this is very strange.  I re-titled the bug to the true problem.  I also marked this as "Works for Me".  This seems like an obscure interaction between various libraries, and possibly Octave code.  If this were an everyday occurrence we would have had many, many reports about it.

The minimal test case would seem to be


system ("touch abc")
unlink ("abc")


1) Which Linux distribution are you using and what version?

2) Are you using a security-hardened version like SELinux?

3) What version of gcc and libc are you using?

4) Are you building from Mercurial sources or from a 5.1.0 tarball?

5) What options are you using with configure?


Rik <rik5>
Group administrator
Tue 09 Apr 2019 10:22:44 AM UTC, comment #14: 

I don't know if this is relevant anyhow:
In config.log for version 4.4.1 there is
| #define ENABLE_DYNAMIC_LINKING 1
which is missing in 5.1.0.

delete() calls the corefunction unlink().

 Dieter Kadelka <dkadelka>
Tue 09 Apr 2019 10:05:18 AM UTC, comment #13: 

Hello Torsten,
with an existing file 'xxx' I started octave-5.1.0 --gui

Here is the result of debugging:

>> dbstop delete

ans =  39

>> delete 'xxx'

stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 39
39:   if (nargin == 0)
debug> dbnext
stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 43
43:   if (iscellstr (varargin))
debug>
stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 44
44:     for arg = varargin
debug>
stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 45
45:       files = glob (arg{1});
debug> files
error: 'files' undefined near line 1 column 1
error: called from
    delete at line 45 column 13
debug>
error: 'files' undefined near line 1 column 1
error: called from
    delete at line 45 column 13
debug> dbnext
stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 46
46:       if (isempty (files))
debug> files
files =
{
  [1,1] = xxx
}

debug> dbnext
stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 49
49:       for i = 1:length (files)
debug>
stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 50
50:         file = files{i};
debug>
stopped in /usr/local/share/octave/5.1.0/m/miscellaneous/delete.m at line 51
51:         [err, msg] = unlink (file);
debug> file
file = xxx
debug> dbnext

and octave freezes. There is no problem with octave-5.1.0 --nogui and octave-4.4.1 --gui

octave-5.1.0 is compiled with gcc version 8.3.0 (GCC), octave-4.4.1 with gcc version 8.2.0 (GCC). Preprocessor m4 is unchanged.

There are some differences in config.log for 5.1.0 and 4.4.1, but I have no idea which are relevant.

Is it possible to debug core function unlink. dbstop unlink is not possible.

 Dieter Kadelka <dkadelka>
Tue 09 Apr 2019 05:39:24 AM UTC, comment #12: 

This might be a deadlock in the inter-process communication between worker thread and GUI. Is it possible to use delete () directly from the console window?

 Torsten Lilge <ttl>
Group Member
Mon 08 Apr 2019 11:16:17 PM UTC, comment #11: 

Hello Rik,
the problem seems to be the command delete and with it unlink.m4
with octave-5.1.0 --nogui
delete('/tmp/octave-help-tBqQGc')
works as expected, but with octave-5.1.0 --gui
octave freezes.

The problem seems to be in line 51 of delete.m:
51:         [err, msg] = unlink (file);

This command freezes octave --gui

Maybe the problem actually is in unlink.m4, lines 46-53
$host_os seems to be not correctly identified.

 Dieter Kadelka <dkadelka>
Mon 08 Apr 2019 10:13:34 PM UTC, comment #10: 

Hello Rik,
with the original version of _makeinfo_.m
I generated /home/xxx/octtmp
Then with

octave-5.1.0 -f --gui
tempdir ()
setenv ("TMPDIR", tilde_expand ("~/octtmp"))
tempdir ()
help sin

>> tempdir()

ans = /tmp/

>> setenv ("TMPDIR", tilde_expand ("~/octtmp"))
>> tempdir()

ans = /home/xxx/octtmp/

>> help sin


with the result that octave hangs. In ~/octtmp is

-rw------- 1 xxx users 3189  9. Apr 00:06 octave-help-mQYpLb
which is not removed.

 Dieter Kadelka <dkadelka>
Mon 08 Apr 2019 09:56:55 PM UTC, comment #9: 

Being UNIX, I wonder if this is really a permissions issue in your temporary directory.

Could you try creating a local temporary directory and using it instead of /tmp?

In a shell, execute


mkdir ~/octtmp
chmod 777 ~/octtmp


Then, start Octave and try the following


octave-5.1.0 -f --gui
tempdir ()
setenv ("TMPDIR", tilde_expand ("~/octtmp"))
tempdir ()
help sin



 Rik <rik5>
Group administrator
Mon 08 Apr 2019 09:43:33 PM UTC, comment #8: 

As a workaround I commented line 153 - 155 in _maininfo_.m out. octave --gui now allows help sin and doc sin.

Of course this is no solution, since octave-hlp-* files in /tmp are not removed.

 Dieter Kadelka <dkadelka>
Mon 08 Apr 2019 09:28:25 PM UTC, comment #7: 

Thanks, actually octave stops at line 154. Here the output:

>> dbstop _makeinfo_

ans =  63

>> help sin

stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 63
63:   if (nargin < 1 || nargin > 3)
debug> dbnext
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 67
67:   if (! ischar (text))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 71
71:   if (! ischar (output_type))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 78
78:   if (nargin < 3)
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 79
79:     if (strcmpi (output_type, "plain text"))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 80
80:       fsee_also = @(T) ["\nSee also:", sprintf(" %s,", T{:})(1:end-1), "\n"];
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 86
86:   if (! is_function_handle (fsee_also))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 92
92:   if (text(2) == " ")
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 96
96:   text = regexprep (text, '^ +@end tex', '@end tex', 'lineanchors');
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 98
98:   file = texi_macros_file ();
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 99
99:   fid = fopen (file, "r");
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 100
100:   if (fid < 0)
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 103
103:     macros_text = fread (fid, Inf, "*char")';
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 104
104:     text = [macros_text text];
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 106
106:   fclose (fid);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 108
108:   if (strcmpi (output_type, "texinfo"))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 115
115:   text = sprintf ("\\input texinfo\n\n%s\n\n@bye\n", text);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 119
119:     template = "octave-help-XXXXXX";
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 120
120:     [fid, name] = mkstemp (fullfile (tempdir, template), true);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 121
121:     if (fid < 0)
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 124
124:     fprintf (fid, "%s", text);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 125
125:     fclose (fid);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 128
128:     switch (lower (output_type))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 130
130:         cmd = sprintf ('%s --no-headers --no-warn --force --no-validate --output=- "%s"',
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 140
140:     [status, retval] = system (cmd);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 143
143:     if (strcmpi (output_type, "plain text"))
debug> status
status = 0
debug> retval
retval =  -- : sin (X)
     Compute the sine for each element of X in radians.

     See also: asin, sind, sinh.


debug> dbnext
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 144
144:       if (numel (retval) > 2 && retval(end-1:end) == "\n\n")
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 145
145:         retval = retval(1:end-2);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 150
150:     retval = regexprep (retval, '^ -- : +', ' -- ', "lineanchors");
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 153
153:     if (exist (name, "file"))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/__makeinfo__.m at line 154
154:       delete (name);
debug>

Dieter Kadelka <dkadelka>
Mon 08 Apr 2019 09:09:55 PM UTC, comment #6: 

Well, this is progress.  Try this now.


dbstop __makeinfo__
help sin
# Now in debugger in __makeinfo__.m
dbnext


Do the same thing as before and step through the file to find the line which causes a problem.  My guess is that it will be line 141 where Octave calls out to the external makeinfo program.


    [status, retval] = system (cmd);


If this is the problem area then you can look at the cmd and try executing it yourself in a shell.

Rik <rik5>
Group administrator
Mon 08 Apr 2019 07:25:07 PM UTC, comment #5: 

Thanks,
I tried your suggestions. Here is the result:

>> dbstop help

ans =  48

>> help sin

stopped in /usr/local/share/octave/5.1.0/m/help/help.m at line 48
48:   if (nargin == 0)
debug> dbnext
stopped in /usr/local/share/octave/5.1.0/m/help/help.m at line 72
72:   elseif (nargin == 1 && ischar (name))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/help.m at line 74
74:     if (strcmp (name, "--list"))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/help.m at line 84
84:     if (strcmp (name, "."))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/help.m at line 95
95:     [text, format] = get_help_text (name);
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/help.m at line 98
98:     switch (lower (format))
debug>
stopped in /usr/local/share/octave/5.1.0/m/help/help.m at line 102
102:         [text, status] = _makeinfo_ (text, "plain text");
debug>

Now octave hangs.

 Dieter Kadelka <dkadelka>
Mon 08 Apr 2019 06:25:48 PM UTC, comment #4: 

I see that "Build docs" is set to "yes" so that looks correct, it found all the tools it needed.

Are you on an esoteric version of Linux?  The next easy step to try would be to see if the version built by the distribution has this problem.  If not, then there is something in the configure options or possibly additional patches that they used to get this to work.

If I had to guess, there is some problem with the info_program() or makeinfo_program().  I think when you try something like "help sin" it is the call to the external program which is hanging.

To debug, I would try


dbstop help
help sin
# Octave will drop you in to the debugger within help.m
dbnext


Execute each line of code in help.m by repeatedly using dbnext (just need to hit return after typing it once) and see where it is hanging.


Rik <rik5>
Group administrator
Mon 08 Apr 2019 06:09:54 PM UTC, comment #3: 

Thank you Rik,
I tried your hints. As you anticipated without any success.

Here are the last lines of config.log:
  Build Octave Qt GUI:                  yes (version: 5)
  JIT compiler for loops:               no
  Build Java interface:                 yes
  Build static libraries:               no
  Build shared libraries:               yes
  Dynamic Linking API:                  dlopen
  Include support for GNU readline:     yes
  64-bit array dims and indexing:       yes
  64-bit BLAS array dims and indexing:  no
  OpenMP SMP multithreading:            yes
  Truncate intermediate FP results:     yes
  Build cross tools:                    no
  Build docs:                           yes

configure: WARNING: sndfile library not found.  The audioinfo, audioread, and audiowrite functions will be disabled.
configure: WARNING: PortAudio library not found.  The audioplayer, audiorecorder, and audiodevinfo functions will be disabled.
configure: WARNING: QScintilla library not found; disabling built-in Qt GUI editor
configure:
configure: NOTE: Libraries or auxiliary programs may be skipped if they are not found
configure: NOTE: OR if they are missing required features on your system.

I think nothing is suspicious.

 Dieter Kadelka <dkadelka>
Mon 08 Apr 2019 03:15:24 PM UTC, comment #2: 

Try starting Octave without reading any configuration files with the -f option like so


octave-5.1.0 -f --gui


I expect there will still be a problem.

You mention that this is a self-compiled version of Octave.  It is possible that you didn't have all the dependencies necessary to create a fully functional version of Octave at the time of the build.  configure will warn about not building the documentation, but doesn't stop you from building an executable.  If you configure with something like


./configure --options >& myconfig.log


then you can inspect the results.  The summary of build options and warnings is at the bottom.

Rik <rik5>
Group administrator
Mon 08 Apr 2019 10:55:14 AM UTC, comment #1: 

works for me in octave 5.1.1 and Ubuntu

 Doug Stewart <dastew>
Mon 08 Apr 2019 10:32:07 AM UTC, original submission:  

After opening octave --gui and typing
help sin (similarly doc sin)
the command window stops working. You can type in any command, but except echoing the command nothing happens.
I removed .config/octave
This does not change anything.
octave --nogui and octave-4.4.1 --gui work fine

octave is build with ./configure

 Dieter Kadelka <dkadelka>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #46744:  have-qscintilla-diffs.txt added by jwe (10KiB - text/plain)
file #46743:  bug56097_v01.patch added by ttl (720B - text/x-patch)
file #46734:  config.log added by dkadelka (55KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by dkadelka (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 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-11 rik5 Open/ClosedOpen Closed
    2019-04-11 rik5 StatusReady For Test Fixed
    2019-04-11 jwe Attached File- Added have-qscintilla-diffs.txt, #46744
    2019-04-11 ttl StatusConfirmed Ready For Test
    2019-04-10 rik5 StatusPatch Reviewed Confirmed
    2019-04-10 rik5 StatusWorks For Me Patch Reviewed
    2019-04-10 ttl Attached File- Added bug56097_v01.patch, #46743
    2019-04-09 rik5 StatusNeed Info Works For Me
        SummaryFreezing of command window after help sin or doc win unlink ("filename") hangs GUI
    2019-04-08 dkadelka Attached File- Added config.log, #46734
    2019-04-08 rik5 StatusNone Need Info

    Back to the top

    Copyright © 2024 Free Software Foundation, Inc.
    Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
    The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
    Page source code

    Powered by Savane 3.14-f13d.
    Corresponding source code