Scilab 6.0.0 Beta 1 crashes when input(a) argument is longer than 64 characters
Reported by j-lan
BUG DESCRIPTION:
----------------
Error message: Scilab 6.0.0(GUI) has stopped working - close program.
ERROR LOG:
----------
HOW TO REPRODUCE THE BUG:
-------------------------
a=input('How can this line cause Scilab 6.0.0 Beta to crash when pressing enter?:');
OTHER INFORMATION:
------------------Activity
assigned to @SciCed
added 6.0.0 Bugzilla Desktop - workspace Major labels
By Antoine Monmayrant
I confirm this bug on my machine (linux 64bits - ubuntu 14.04) with 6.0.0-beta, while there is no problem with 5.5.1.
Antoine
PS: here is the error I got on the command line:
mymachine:scilab $ betascilab Une erreur grave a été détectée par Scilab. Votre instance va probablement se fermer inopinément. Ce problème provient sûrement de vos pilotes de cartes graphiques à l'utilisation d'une fonctionnalité graphique dans Scilab. Veuillez les mettre à jour et ré-essayer . Vous pouvez rapporter un bug sur http://bugzilla.scilab.org/ avec :
- un extrait de code qui reproduit le bug
- le résultat de [a, b] = getdebuginfo()
- les informations suivantes : [mymachine:16495] Signal: Segmentation fault (11) [mymachine:16495] Signal code: (128) [mymachine:16495] Failing at address: (nil)
Pile d'appel : 1: 0x914da6 <JVM_handle_linux_signal> (/home/myhome/softs/scilab-6.0.0-beta-1/thirdparty/java//lib/amd64/server/libjvm.so) 2: 0x90b6f3 < > (/home/myhome/softs/scilab-6.0.0-beta-1/thirdparty/java//lib/amd64/server/libjvm.so) 3: 0x10340 < > (/lib/x86_64-linux-gnu/libpthread.so.0) 4: 0x82e0c (/lib/x86_64-linux-gnu/libc.so.6) 5: 0x4b7e (/home/myhome/softs/scilab-6.0.0-beta-1/lib/scilab/libsciconsole-minimal.so.6) 6: 0x4a61 <setprlev_> (/home/myhome/softs/scilab-6.0.0-beta-1/lib/scilab/libsciconsole-minimal.so.6) 7: 0x1d0608 <scilabReadAndStore(void*)> (/home/myhome/softs/scilab-6.0.0-beta-1/lib/scilab/libscilab-cli.so.0) 8: 0x8182 < > (/lib/x86_64-linux-gnu/libpthread.so.0) 9: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 10: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 11: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 12: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 13: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 14: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 15: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 16: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 17: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 18: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 19: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 20: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 21: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 22: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 23: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 24: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 25: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 26: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 27: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 28: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 29: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 30: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 31: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 32: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 33: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 34: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 35: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 36: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 37: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 38: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 39: 0xfa47d (/lib/x86_64-linux-gnu/libc.so.6) 40: 0xfa47d
-
By Leonardo José Consoni
fix_large_input_message.patch (1.07 KB, text/plain)
Increase PROMPT_SIZE_MAX to 128
I found that it was caused by the 64 characters limit of PROMPT_SIZE_MAX. A quick hack of raising that value avoided the problem.
Doesn't look like the optimal solution, though.
-
By Pierre-Aime AGNEL
(In reply to Leonardo José Consoni from comment #2)
Created attachment 4287 [details] Increase PROMPT_SIZE_MAX to 128
I found that it was caused by the 64 characters limit of PROMPT_SIZE_MAX. A quick hack of raising that value avoided the problem.
Doesn't look like the optimal solution, though.
Thank you for the analysis there is a first suggested correction here https://gitlab.com/scilab/legacy_codereview/-/wikis/changes/17813/
But you are right as stated in the comments on the codereview above, we need to protect a little the PROMPT_SIZE_MAX A first correction could be to raise it to 1024 and protect the sci_prompt function to avoid setting the prompt to more characters.
The fix Adeline suggests is to first display the message then call a prompt maybe a standard prompt for user input awaited could be a good solution Suggestions: -?> ?>> Input>
what do you think?
-
By Leonardo José Consoni
(In reply to Pierre-Aime AGNEL from comment #3)
(In reply to Leonardo José Consoni from comment #2)
Created attachment 4287 [details] Increase PROMPT_SIZE_MAX to 128
I found that it was caused by the 64 characters limit of PROMPT_SIZE_MAX. A quick hack of raising that value avoided the problem.
Doesn't look like the optimal solution, though.
Thank you for the analysis there is a first suggested correction here https://gitlab.com/scilab/legacy_codereview/-/wikis/changes/17813/
But you are right as stated in the comments on the codereview above, we need to protect a little the PROMPT_SIZE_MAX A first correction could be to raise it to 1024 and protect the sci_prompt function to avoid setting the prompt to more characters.
The fix Adeline suggests is to first display the message then call a prompt maybe a standard prompt for user input awaited could be a good solution Suggestions: -?> ?>> Input>
what do you think?
Thanks for the quick comment.
As I understand, the problem lies in "prompt.c" file, at the functions "SetTemporaryPrompt", which sets the pointer "temporaryPrompt" for the prompt message, and "C2F", which does the actual copy ("strcpy(Sci_Prompt, temporaryPrompt);"). Am I right ?
If we check for a string longer than 1024 chars when setting the prompt, should we return an error, avoid the copy completely or use strncpy() ?
I think the "input>" prompt string is more consistent with the other defined in "prompt.h" header ("SCIPROMPTDEBUG" and "SCIPROMPTBREAK"). But are we including it there (with "SCIPROMPTINPUT" define or something) ? If so, how to detect it is an input operation ?
Sorry for possibly bad English. I hope you understand my questions well.
-
By Cédric DELAMARRE (@SciCed)
proposal fix : https://gitlab.com/scilab/legacy_codereview/-/wikis/changes/17813/
- The "input" function prints the input argument string instead of putting it in the prompt. The prompt is set to empty string.
- The "prompt" function returns an error when the string exceeds 63 characters.
-
By Pierre-Aime AGNEL
(In reply to Cédric DELAMARRE from comment #5)
proposal fix : https://gitlab.com/scilab/legacy_codereview/-/wikis/changes/17813/
- The "input" function prints the input argument string instead of putting it in the prompt. The prompt is set to empty string.
- The "prompt" function returns an error when the string exceeds 63 characters.
Merged @ da962feb
-
By Samuel GOUGEON (@sgougeon)
This raw patch causes more errors than it solves:
-
The #14424 (closed) is due to it.
-
now, all messages must take into account mprintf() limitations or requirements:
- "%" character yields errors: input("Required % of tin:", "string") --> input("Required % of tin:", "string") at line 36 of function input ( SCI\modules\io\macros\input.sci line 50 ) mprintf : Nombre erroné d'arguments d'entrée : Les données ne correspondent pas au format.
- backslashes are parsed "à la C" and are eaten instead of being simply echoed:
...
-
mentioned in issue #14376 (closed)
mentioned in issue #14424 (closed)