https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4377 Lustre <p>Seen in Lustre 2.5<br/> This sequence of commands seems to reproduce the fault.</p> <ol> <li>lst<br/> lst &gt; new_session<br/> Invalid parameters list in command line<br/> lst &gt; new_session a<br/> Invalid parameters list in command line<br/> lst &gt; end_session<br/> Invalid parameters list in command line<br/> lst &gt; stop<br/> Segmentation fault</li> </ol> LU-4377

Segmentation fault seen in LNet Self Test sub-shell

Bug Minor Resolved Fixed Amir Shehata Brett Lee Wed, 11 Dec 2013 17:46:11 +0000 Tue, 22 Dec 2015 03:26:03 +0000 Thu, 23 Jul 2015 22:09:46 +0000 Lustre 2.5.0 Lustre 2.6.0 Lustre 2.7.0 0 3 <p>found the reason of the crash<br/> when you do "new_session a" the following code gets executed (under jt_lst_new_session) :<br/> if (optind == argc - 1) {<br/> name = argv<span class="error">&#91;optind ++&#93;</span>;<br/> if (strlen(name) &gt;= LST_NAME_SIZE) </p> { fprintf(stderr, "Name size is limited to %d\n", LST_NAME_SIZE - 1); return -1; } <p>This increments optind unnecessarily and never resets it before the call to the next getopt_long() which causes the crash. Looking at the code it appears that this issue is repeated several times in the code. It appears that the assumption is that lst is never executed interactively. When it is executed interactively optind needs to be reset in order for getopt_long() to start scanning from the beginning of the command line.</p> <p>The same crash can be observed if you do:<br/> new_session a<br/> new_session</p> Related LU-6025 Development Rank 1|hzwb7j: Rank (Obsolete) 11992 Severity