[Openmcl-devel] Newest lx86cl64 crashes on newest RedHat
Paul.Meurer at uni.no
Wed Apr 6 02:59:23 PDT 2011
Am 06.04.2011 um 11:38 schrieb Gary Byers:
> 2.6.18 is several years old (was released in 2006), though it looks
> like the particular kernel you're using was built more recently (with
> an unknown set of mystery patches.)
I see. It's our IT department who does the updating, and I was in the belief that they updated to new versions. Surprise.
> We stopped using the MAP_GROWSDOWN option a long time ago (early September 2010).
I remember that, and it also fixed a similar problem I had then.
> The two possibilities that come to mind are:
> - the lx86cl64 binary that you're using is very old. This can happen if the
> file's been locally modified: 'svn update' will refuse to overwrite the
> file in that case. You can do:
> $ cd ccl
> $ svn revert lx86cl64
> and if that says that it reverted the file and that fixes the problem, you owe
> me US $8.
Even if I somehow feel that I owe you more than US $8, you won't get these $8. It does not fix the problem, my binary was up-to-date.
> - MAP_GROWSDOWN isn't being used, but the Linux kernel that you're using returns
> an unmapped page anyway. I have not seen this behavior in the kernels
> distributed by current Ubuntu or Fedora releases and I don't know how that
> behavior would not be a bug in mmap(). This doesn't seem very likely.
> The code in question has called MapMemoryForStack(), which in turn calls mmap()
> with some standard/portable options. If that returns something other than
> MAP_FAILED, the address that mmap() returns is returned to create_stack(), which
> then tries to to store the size of the stack in the word at that address. If
> you get a bus error at that point, then I can't think of a reason for that besides
> those mentioned above.
Thanks for the explanation. I will investigate this further with our IT people.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel