Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash in dpivotL() due to uninitialized variable #33

Open
coronasky opened this issue Aug 14, 2019 · 3 comments
Open

Crash in dpivotL() due to uninitialized variable #33

coronasky opened this issue Aug 14, 2019 · 3 comments

Comments

@coronasky
Copy link

Hi Xiaoye,

When using superLU, I found a crash in dpivotL() caused by possible uninitialized variable.
The issue happens when the sparse matrix is singular, with a few all-zero rows/columns.
Where is the stacktrace:

Thread 187 "test" received signal SIGSEGV, Segmentation fault.
0x00000000199ff995 in dpivotL (jcol=0, u=1, usepr=0x2aab03dc86d4, perm_r=0x2aab0bbfd304, iperm_r=0x0, iperm_c=0x2aab02534208, pivrow=0x2aab03dc86e0, Glu=0x2aab03dc88c0, stat=0x2aab03dc8940)
    at dpivotL.c:138                                                                                                                                                                         
138             perm_r[*pivrow] = jcol;
(gdb) where 
#0  0x00000000199ff995 in dpivotL (jcol=0, u=1, usepr=0x2aab03dc86d4, perm_r=0x2aab0bbfd304, iperm_r=0x0, iperm_c=0x2aab02534208, pivrow=0x2aab03dc86e0, Glu=0x2aab03dc88c0, stat=0x2aab03dc8940)
    at dpivotL.c:138
#1  0x00000000199f9dad in dgstrf (options=0x2aab03dc8970, A=0x2aab03dc88a0, relax=10, panel_size=20, etree=0x2aab0bbfd36c, work=0x0, lwork=0, perm_c=0x2aab0bbfd338, perm_r=0x2aab0bbfd304,
    L=0x2aab0bbfd178, U=0x2aab0bbfd198, Glu=0x2aab03dc88c0, stat=0x2aab03dc8940, info=0x2aab03dc889c) at dgstrf.c:333

Because of the all-zero rows, Glu->lsub[] 's elements are not initialized. I believe they would be properly set in dsnode_dfs() if the rows/columns are non-zero.
Due to this problem, the function crashed at line 138:

    /* Test for singularity */
    if ( pivmax == 0.0 ) {
#if 1
	*pivrow = lsub_ptr[pivptr];
	perm_r[*pivrow] = jcol;         <--------- here
#else
	perm_r[diagind] = jcol;
#endif
    usepr = 0;
	return (jcol+1);
    }

I have no idea what's behind the "#if 1" condition. Maybe there are other considerations for the singularity?
But if I change it to "#if 0", then the crash is gone.
Would you please take a look at this problem? Probably the same issue exists in single and complex versions.

Regards,
Haotian

@sud-a
Copy link

sud-a commented Apr 30, 2021

Hi Xiaoye Sherry Li,

I am facing the same issue mentioned by @coronasky for a singular sparse matrix. The program crashes at the below line:

perm_r[*pivrow] = jcol;

As described by @coronasky , this seems to be an issue with the uninitialized variable "pivrow"

pivrow

Can you please look into this problem and share your comments?

I would also like to know the motivation of using "#if 1" condition since the code inside #else will never run. Similar to the observation of @coronasky , there is no crash if I edit it to "#if 0". Can we keep it as "#if 0" and what are the implications of doing so?

Regards,
Sudhindra

@xiaoyeli
Copy link
Owner

The old "#else" branch is not correct if there are several "numerical zeros" in the current column.

Seems like your matrix is structurally zero in that column, and the column is not represented in the meta data structure?

At the crash point, can you print out the following variables: fsupc, nsupc, nsupr, pivptr, lsub_ptr[pivptr],
(you can do this inside a debugger, e.g., gdb)

@sud-a
Copy link

sud-a commented Aug 4, 2021

Hi Xiaoye,

Thanks for your reply. The matrix for my case is 2x2 in size and singular. I have provided this sparse linear system below for your analysis.
crash

Any help on this will be greatly appreciated.

Regards,
Sudhindra

eschnett pushed a commit to eschnett/superlu that referenced this issue Oct 13, 2022
fix compile errors with 64bit-indices build
eschnett pushed a commit to eschnett/superlu that referenced this issue Oct 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants