{"action":"created","issue":{"url":"https://api.github.com/repos/numpy/numpy/issues/5899","labels_url":"https://api.github.com/repos/numpy/numpy/issues/5899/labels{/name}","comments_url":"https://api.github.com/repos/numpy/numpy/issues/5899/comments","events_url":"https://api.github.com/repos/numpy/numpy/issues/5899/events","html_url":"https://github.com/numpy/numpy/pull/5899","id":78780003,"number":5899,"title":"MAINT: use more conservative integer types for umath linalg","user":{"login":"argriffing","id":101416,"avatar_url":"https://avatars.githubusercontent.com/u/101416?v=3","gravatar_id":"","url":"https://api.github.com/users/argriffing","html_url":"https://github.com/argriffing","followers_url":"https://api.github.com/users/argriffing/followers","following_url":"https://api.github.com/users/argriffing/following{/other_user}","gists_url":"https://api.github.com/users/argriffing/gists{/gist_id}","starred_url":"https://api.github.com/users/argriffing/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/argriffing/subscriptions","organizations_url":"https://api.github.com/users/argriffing/orgs","repos_url":"https://api.github.com/users/argriffing/repos","events_url":"https://api.github.com/users/argriffing/events{/privacy}","received_events_url":"https://api.github.com/users/argriffing/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-05-21T01:53:12Z","updated_at":"2015-05-21T19:27:05Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/numpy/numpy/pulls/5899","html_url":"https://github.com/numpy/numpy/pull/5899","diff_url":"https://github.com/numpy/numpy/pull/5899.diff","patch_url":"https://github.com/numpy/numpy/pull/5899.patch"},"body":"I'm not sure this is useful or even works."},"comment":{"url":"https://api.github.com/repos/numpy/numpy/issues/comments/104394877","html_url":"https://github.com/numpy/numpy/pull/5899#issuecomment-104394877","issue_url":"https://api.github.com/repos/numpy/numpy/issues/5899","id":104394877,"user":{"login":"argriffing","id":101416,"avatar_url":"https://avatars.githubusercontent.com/u/101416?v=3","gravatar_id":"","url":"https://api.github.com/users/argriffing","html_url":"https://github.com/argriffing","followers_url":"https://api.github.com/users/argriffing/followers","following_url":"https://api.github.com/users/argriffing/following{/other_user}","gists_url":"https://api.github.com/users/argriffing/gists{/gist_id}","starred_url":"https://api.github.com/users/argriffing/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/argriffing/subscriptions","organizations_url":"https://api.github.com/users/argriffing/orgs","repos_url":"https://api.github.com/users/argriffing/repos","events_url":"https://api.github.com/users/argriffing/events{/privacy}","received_events_url":"https://api.github.com/users/argriffing/received_events","type":"User","site_admin":false},"created_at":"2015-05-21T19:27:05Z","updated_at":"2015-05-21T19:27:05Z","body":"@jaimefrio I'm pretty sure the reason for the segfault in https://github.com/numpy/numpy/issues/5898 is that\r\n1) After working around some overflow problems, the numpy allocation code no longer attempts to allocate a negative number of things, so it no longer prematurely returns from the function call.  Therefore it actually reaches the point of calling the underlying LAPACK dgesv function.\r\n2) Some implementations of the underlying LAPACK function (e.g. OpenBLAS, apparently) can deal with input matrices of size `NxN`, even with an interface that uses int32 for `N` and even if `N*N` would overflow 32 bits.  For example OpenBLAS uses `blasint` for its interface (e.g. for passing `N`) which sounds like it could be 32-bit, whereas the function that does the actual indexing uses `BLASLONG` which sounds less likely to overflow.\r\nhttps://github.com/xianyi/OpenBLAS/blob/develop/interface/lapack/gesv.c\r\nhttps://github.com/xianyi/OpenBLAS/blob/develop/lapack/getrf/getrf_single.c\r\nBut the numpy lapack-lite implementation seems to internally use int32 indices into the flat `NxN` memory which overflows and segfaults.\r\nhttps://github.com/numpy/numpy/blob/maintenance/1.9.x/numpy/linalg/lapack_lite/f2c.h#L10\r\nhttps://raw.githubusercontent.com/numpy/numpy/maintenance/1.9.x/numpy/linalg/lapack_lite/dlapack_lite.c\r\n\r\nMy understanding from https://github.com/numpy/numpy/issues/5898#issuecomment-104315105 is that the blas-lite and lapack-lite included with numpy are already known to cause segfaults for these larger matrices (e.g. using `dot`) because of overflow issues like this.\r\n\r\nI'm not 100% sure that this is what's going on with the segfault, but this is my best guess.  Maybe wait for comments or a review from @pv or others before merging?"}}