https://en.wikipedia.org/wiki/Bus_error <https://en.wikipedia.org/wiki/Bus_error>
But perhaps not true for Intel? > On Aug 24, 2020, at 1:06 PM, Matthew Knepley <[email protected]> wrote: > > On Mon, Aug 24, 2020 at 1:46 PM Barry Smith <[email protected] > <mailto:[email protected]>> wrote: > > > > On Aug 24, 2020, at 12:39 PM, Jed Brown <[email protected] > > <mailto:[email protected]>> wrote: > > > > Barry Smith <[email protected] <mailto:[email protected]>> writes: > > > >>> On Aug 24, 2020, at 12:31 PM, Jed Brown <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> Barry Smith <[email protected] <mailto:[email protected]>> writes: > >>> > >>>> So if a BLAS errors with SIGBUS then it is always an input error of just > >>>> not proper double/complex alignment? Or some other very strange thing? > >>> > >>> I would suspect memory corruption. > >> > >> > >> Corruption meaning what specifically? > >> > >> The routines crashing are dgemv which only take double precision arrays, > >> regardless of what garbage is in those arrays i don't think there can be > >> BUS errors resulting. They don't take integer arrays whose corruption > >> could result in bad indexing and then BUS errors. > >> > >> So then it can only be corruption of the pointers passed in, correct? > > > > Such as those pointers pointing into data on the stack with incorrect sizes. > > But won't incorrect sizes "usually" lead to SEGV not SEGBUS? > > My understanding was that roughly memory errors in the heap are SEGV and > memory errors on the stack are SIGBUS. Is that not true? > > Matt > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
