Adam,
I tried that, but gdb receives SIGSEGV immediately after calling "munmap"...
GDB shows the fault address as a "next to `munmap` jump instruction". I took
objdump of the image to
confirm this.
But i believe, program is getting an exception while returning from munmap
syscall. As
it tries to jump back to the user space address, but doesn't find any valid
tlb / page table
entry and it takes a invalid fault..
I am still not able to understand that how any architecture would allow
access to any
"unmapped" segment without any page table / tlbs info ? Is the "constructor"
code in
libhugetlbfs sits under any specific segment other than ".text" which is never
unmapped ??
thanks,
Mehul.
--- On Mon, 1/5/09, Adam Litke <a...@us.ibm.com> wrote:
From: Adam Litke <a...@us.ibm.com>
Subject: Re: [Libhugetlbfs-devel] Lib hugetlbfs
To: mehu...@yahoo.com
Cc: "Nishanth Aravamudan" <n...@us.ibm.com>,
libhugetlbfs-devel@lists.sourceforge.net
Date: Monday, January 5, 2009, 12:40 PM
On Mon, 2009-01-05 at 10:25 -0800, mehul vora wrote:
>
> Adam,
>
> I just commented out printfs, but still program gets a seg fault. I
> have a tight loop after "munmap", so ideally program should
never come
> out, but for me program gets a SIGSEGV after first munmap....
>
> Could you run your program in gdb and determine the address that is
> causing the segfault? You could compare that address to `readelf -e`
> and `nm` output for your binary to better determine the nature of the
> error.
>
------------------------------------------------------------------------------
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
