Re: [m5-users] thread alloc/dealloc error and stat64 system call

Wed, 13 Jun 2007 11:18:59 -0700 


On Jun 13, 2007, at 2:10 PM, Jiayuan Meng wrote:
Thanks Steve and Ali! I didn't know that there are different versions of malloc in multi-threaded applications.
I tried two things, first, link the program with -lpthread -static. Sadly, this gives the same problem. Do I need to call any function to invoke the thread-safe malloc? in my implementation, no pthread functions are called. Creating a thread is just as calling a function with a separate stack and moving the function's PC to another cpu. ( a "my_exit" instruction is inserted before the function return) 
No idea.
second, I tried to set a breakpoint at the system call "obreakFunc" to see what happened during malloc. But interestingly, the simulator doesn't go to this break point during the whole life span of the created thread, even though the thread has a "new" or "malloc" statement. Am i missing something?
The brk is only changed when malloc needs more memory than it has available (I think it normally gets a page or more at a time), so it's completely possible that brk would never get called if you aren't malloc()ing a lot of data.
It doesn't seems like you're benchmark is doing a whole lot right now, so you could run with --trace-flags=Exec and look at the instruction stream of all the threads. That should provide you with some insight as to what functions are being called and what is going on. 

Ali


Need your help again~

Thank you!

Jiayuan

----- Original Message -----
From: "Steve Reinhardt" <[EMAIL PROTECTED]>
To: "M5 users mailing list" <[email protected]>
Sent: 2007年6月13日 12:29 PM
Subject: Re: [m5-users] thread alloc/dealloc error and stat64 system call
My guess is also that you've linked with a version of malloc that's not thread-safe. Try linking your application with -lpthread; that should 
link with the thread-safe libraries.

Steve

Ali Saidi wrote:

Hi Jiayuan,

I'm not completely sure, it really depends on what you're new thread
code is doing. From a simulation stand point all M5 is doing is
providing an implementation of the brk() syscall. If malloc() increases 
the break size, physical frames are allocated and mapped the virtual
addresses between the old brk and the new one (syscall_emul.cc: 110). I 
can't see how this would be a problem, but no guarantees.  My guess
would be something to do with malloc() not expecting a threaded process. 

Ali

On Jun 12, 2007, at 11:26 PM, Jiayuan Meng wrote:


Hi Ali,
Thanks for the hint and I did find that there is an error. But I'm not 
sure whether it's the problem with my implementation or with M5.

Here is the problem:


void thread_main()
{
    int* x = new x[10];
    delete [] x;
    my_exit(); // inlined assembly(asm volatile (".byte 0x61,
0x00,0x00,0x40))
}

main()
{
    for(int n=0; n<4; n++)
thread_create(&thread_main); // inlined assembly(asm volatile 
(".byte 0x62, 0x00,0x00,0x40))
    wait(); // inlined assembly(asm volatile (".byte 0x63,
0x00,0x00,0x40))
}

in the following example, I am trying to create 4 threads running
simultaneously. Each of the thread allocate some heap space and then 
free it.
I am expecting that the "x"s in each thread is assigned to a different address in the heap. But I found that the 4 threads allocate exactly the same address to the 4 "x"s, thus, when they try to free "x", it is 
freed four times and the application invokes an error:
*** glibc detected *** double free or corruption (fasttop):
0x00000001201d8a40 ***
and this error is always followed by the "stat64 unimplemented" message.
Can you also give me some hints about how to solve this? why does the four threads assign their "x" the same address? how can I get around 
with this?

Thanks!

Jiayuan




    ----- Original Message -----
    *From:* Ali Saidi <mailto:[EMAIL PROTECTED]>
    *To:* M5 users mailing list <mailto:[email protected]>
    *Sent:* 2007年6月13日 10:24 AM
    *Subject:* Re: [m5-users] thread alloc/dealloc error and stat64
    system call
I'm not sure I know why stat64 is being called. It could be that 
    one of your new instructions isn't what you think it is and the
program execution path changes to some error handler, or something 
    else. You probably want to create an instruction trace and make
    sure it's doing what you think it is. If that is the case then
implementing stat64 shouldn't be that difficult, just take a look 
    at fstat64. stat64 is the same thing but instead of argument 1
    being a file descriptor it's a path to a file.

    Ali

    On Jun 12, 2007, at 8:14 PM, Jiayuan Meng wrote:


    Hi all,

    As I am trying to run a thread in SE mode, I made up the
    following code:

    void thread_main()
    {
        int* x = new x[10];
        delete [] x;
        my_exit(); // inlined assembly(asm volatile (".byte 0x61,
    0x00,0x00,0x40))
    }

    main()
    {
        launch(&thread_main); // inlined assembly(asm volatile
    (".byte 0x62, 0x00,0x00,0x40))
        wait(); // inlined assembly(asm volatile (".byte 0x63,
    0x00,0x00,0x40))
    }
To launch this thread, what I did was: allocate a stack, assign the pc, and activate the thread context on another cpu. my_exit() 
    will tell the simulator that this thread is finished and the
    simulator will deallocate/halt its thread context.

    The extened assemblies are implemented following the M5FUNC
    pseudo instructions.
I use crosstool's g++ 3.4.3 to compile the code to alpha- linux. 
    M5 is compiled on a 64bit x86 machine.

    I get the following message:
    fatal: syscall stat64 (#425) unimplemented.

    how ever, if I just change the thread_main to:
    void thread_main()
    {
        int* x = new x
        delete x;
        my_exit();
    }
The error will be gone. What can I do to allow the first case to 
    work? is there any patch for system call stat64?

    Thanks!

    Jiayuan
------------------------------------------------------------------- ----- 

    _______________________________________________
    m5-users mailing list
    [email protected] <mailto:[email protected]>
    http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
-------------------------------------------------------------------- ---- 

_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users


_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users

Reply via email to