I'm thinking of something such as writing floating point data into the return address, which would be unaligned/garbage.
Reproducing under Valgrind would help a lot. Perhaps it's possible to checkpoint such that the breakage can be reproduced more quickly? Barry Smith <[email protected]> writes: > 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/>
