On Mon, 2009-01-05 at 11:08 -0800, mehul vora wrote:
> 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 ??
> 
> Since libhugetlbfs is a library, it has it's own text and data
> segments (independent of the program).  So the library code runs
> uninhibited since only the program segments (not the library segments)
> are 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

Reply via email to