#6 buildlist method crash when move with arrows

[Dimitris Zlatanidis]

I use Python 2.7.5

Screenshot http://postimg.org/image/pkrj4cpib/

[Florent Rougon]

Hello,

I can't reproduce this with the pythondialog 3.3.0 demo. I tried all arrows during the part of the demo that uses buildlist, including the numeric keypad with NumLock turned off. It just moves focus as expected.

Your traceback seems to indicate dialog was terminated by a signal, but it is incomplete. It should indicate the number of the signal that killed dialog, however apparently python2-pythondialog exits before the stream where this is printed is flushed to stderr (the "normal" pythondialog, i.e., for Python 3, does not have this problem). I suggest you add u_stderr.flush() before sys.exit(1) at the very end of examples/demo.py, like this:

    print("Error (see above for a traceback):\n\n{0}".format(
            exc_instance), file=u_stderr)
    u_stderr.flush()
    sys.exit(1)

With this temporary change, if I run:

PYTHONPATH=. python2 examples/demo.py -f 2>/tmp/dia_err

and send the HUP signal (number 1) to dialog with:

kill -HUP dialog_pid

then I get a traceback + error message like this in /tmp/dia_err:

Traceback (most recent call last):
File "examples/demo.py", line 1704, in main
app.run()
File "examples/demo.py", line 416, in run
self.demo()
File "examples/demo.py", line 439, in demo
width=60, height=17)
File "examples/demo.py", line 242, in wrapper
res = method(args, kwargs)
File "/home/flo/src/python/pythondialog/dialog.py", line 3016, in msgbox
kwargs)
File "/home/flo/src/python/pythondialog/dialog.py", line 1760, in _widget_with_no_output
code, output = self._perform(args, *kwargs)
File "/home/flo/src/python/pythondialog/dialog.py", line 1541, in _perform
args_file)
File "/home/flo/src/python/pythondialog/dialog.py", line 1502, in _handle_program_exit
child_output_rfd)
File "/home/flo/src/python/pythondialog/dialog.py", line 1441, in _wait_for_program_termination
os.WTERMSIG(exit_info))
DialogTerminatedBySignal

Error (see above for a traceback):

dialog-like terminated by a signal: the dialog-like program was terminated by signal 1

which is more helpful since it gives us the signal number.

So, I suggest you try this to see which signal is killing dialog in your case. It does not sound like a pythondialog bug but more like a misconfigured terminal, though.

You should also indicate which pythondialog version you are using for completeness. It is printed in the first screen of the demo. Your program can print it with dialog.version too in case it does not run with the same Python or pythondialog installation as the demo.

[Florent Rougon]

Not even sure adding the u_stderr.flush() is necessary. There is an atexit call at line 127 of demo.py that should do the same, and apparently works well now that I try it again. Maybe I forgot to scroll the log file when I thought the flush() was necessary? Hmmm.

Please do the test I said, first without adding the u_stderr.flush(), then adding it only if the /tmp/dia_err file doesn't contain the error message with signal number (and tell me whether you had to add the line).

[Dimitris Zlatanidis]

Ok i added u_stderr.flush() in the demo.py and get the same error:

http://postimg.org/image/dee14kjl5/

[Florent Rougon]

OK.

1) Can you please confirm that it was necessary to add the u_stderr.flush() in demo.py in order to see the signal number (11) in the error message? This is a bit weird, but it really necessary, I'll add it in the next pythondialog release.

2) So, your dialog program (not the Python process using pythondialog) was killed by signal 11, which is SIGSEGV on POSIX systems according to the signal(7) manpage ("Segmentation fault"). This indicates a problem with your dialog program (maybe linked to incompatible libraries, or having a particular memory-related bug) or at a lower level (kernel/computer memory...).

pythondialog cannot do anything about it. Either you find what is wrong in the way your dialog program was compiled (or your computer), or you can report the problem to the dialog maintainer after reproducing it from the command line. You can obtain the equivalent dialog command lines of Dialog method calls with Dialog.setup_debug(). cf. the "Troubleshooting" section at https://pypi.python.org/pypi/python2-pythondialog

Don't forget to use the 'expand_file_opt' option in Dialog.setup_debug() if you use pythondialog 3.3 or later, otherwise the commands you'll obtain will only refer to temporary files.

[Dimitris Zlatanidis]

Yes you are right,

Upgrade dialog from version 1.2_20130523 to version 1.2_20150528 and everything go well. I am sorry for confusing.

[Dimitris Zlatanidis]

Perhaps useful for another user in Slackware Linux can be found here upgrade dialog. https://github.com/dslackw/slacks/tree/master/dialog

[Florent Rougon]

(If you are the author of the page you linked to, the dialog program is normally written all-lowercase as far as I can tell.)

Glad to see your problem is solved now. Since it wasn't in pythondialog, I am going to close this bug, but you didn't answer to the first question in this comment:

https://sourceforge.net/p/pythondialog/bugs/6/#4e62

I tried again to reproduce the problem (missing message with the signal name) with unpatched demo.py (i.e., no u_stderr.flush() added), but it didn't happen. So I am not sure it is necessary to add it for future releases. Normally, it shouldn't be needed with the atexit call I mentioned, but I'd like to be sure.

[Dimitris Zlatanidis]

No it is not necessary.
I have answered here:
https://sourceforge.net/p/pythondialog/bugs/6/#5511

[Florent Rougon]

The answer you are pointing to says you could see the signal number after adding u_stderr.flush(), but it doesn't say if the signal number was displayed even without adding u_stderr.flush(). Oh well...

[Florent Rougon]

Closing, since this is not a pythondialog bug.