[PATCHv4] print stack trace after each syscall
Masatake YAMATO
yamato at redhat.com
Mon Oct 7 04:42:38 UTC 2013
About the advice I got, see following pages:
http://lists.nongnu.org/archive/html/libunwind-devel/2013-09/msg00009.html
http://lists.nongnu.org/archive/html/libunwind-devel/2013-10/msg00001.html
Based on the advice I'm thinking following functions to libunwind:
+
+extern int unw_get_image (unw_cursor_t *, unw_image_t **);
+extern int unw_get_proc_name_in_image (unw_image_t *, unw_cursor_t *, char *, size_t, unw_word_t *);
+extern int unw_get_path_in_image (unw_image_t *, char *, size_t);
+extern void unw_destroy_image (unw_image_t *);
+
With image, we can get both proc_namd and path at once.
Further more, image can use as cache object; once image object is built
we cat reuse it again and again till the target program invokes mmap or execve.
What strace has to do is just managing image objects.
However, it will take some time to implement the functions, so
I will revise and resubmit the last patch for strace first.
Masatake YAMATO
On Mon, 07 Oct 2013 01:00:14 +0900 (JST), Masatake YAMATO <yamato at redhat.com> wrote:
>> Hey Masatake,
>> Are you gonna send a patch to fix the map reloading even when using -e?
>>
>> I don't mean to hurry you, I was wondering how do you want to proceed.
>
> Luka, I'm sorro ty be late to report the status.
>
> I'm working on libunwind now.
> See my post:
>
> http://lists.nongnu.org/archive/html/libunwind-devel/2013-09/msg00000.html
>
> I got an advice privately fro a developer.
> I'll ask the developer whether I can forward the mail of advice
> here.
>
> Masatake
>
>
>> On Sat, Sep 21, 2013 at 6:45 PM, Luca Clementi <luca.clementi at gmail.com> wrote:
>>> On Sat, Sep 21, 2013 at 12:54 PM, Masatake YAMATO <yamato at redhat.com> wrote:
>>>> Hi,
>>>>
>>>> Thank you for reviewing the patch.
>>>> But I need more discussion.
>>>>
>>>> On Thu, 19 Sep 2013 18:05:06 -0700, Luca Clementi <luca.clementi at gmail.com> wrote:
>>>> ...
>>>>>> Why delete_mmap_cache invocation is needed after wait related system calls?
>>>>>>
>>>>>
>>>>> I can't find a logical explanation for that.
>>>>> I think that part of the code should be removed as you indicated.
>>>>
>>>> O.k. Let's remove the code block.
>>>>
>>>> On Thu, 19 Sep 2013 18:05:06 -0700, Luca Clementi <luca.clementi at gmail.com> wrote:
>>>>> Although I have one minor comment.
>>>>> Since we are printing the stack trace on return of a sys call,
>>>>> shouldn't we update the mapping _before_ we print the stack trace?
>>>>> In most of the situation it does not matter except for execve (we can
>>>>> avoid a "backtracing_error").
>>>>>
>>>>> I simply moved the delete_mmap_cache up in the trace_syscall_exiting:
>>>>
>>>>
>>>> I think there is no difference between _after_ and _before_.
>>>>
>>>>
>>>> Let's think about calling mmap then getpid.
>>>>
>>>> ** _after_ case **
>>>>
>>>> -1. mmap run in kernel and the map of process is modified.
>>>> 0. control for mmap syscall is returned from kernel, then
>>>> 1. the stack for calling mmap is printed, then
>>>> 2. the cache is cleared, then
>>>> 3. getpid is called, then
>>>> 4. cache is rebuilt (in print_stack), then
>>>> 5. the stack for calling getpid is printed(in print_stack).
>>>>
>>>> Note: the map is refereed in 4 but between 0 and 5, the map for
>>>> the process is not modified.
>>>>
>>>> ** _before_ case **
>>>>
>>>> -1. mmap run in kernel and the map of process is modified.
>>>> 0. control for mmap syscall is returned from kernel, then
>>>> 1. the cache is cleared, then
>>>> 2. cache is rebuilt (in print_stack), then
>>>> 3. the stack for calling mmap is printed, then
>>>> 4. getpid is called, then
>>>> 5. the stack for calling getpid is printed using the cache
>>>> built in 2.
>>>>
>>>> In the both case, when printing the stack trace for getpid, newer
>>>> cache is used.
>>>>
>>>> As you wrote, execve is special.
>>>> We are interested in the context of execve invoked.
>>>> So we should capture the stack in `trace_syscall_entering'.
>>>> After execve, the context is destroyed.
>>>
>>> I agree on this, but in this way you will have to buffer the output
>>> and print it only in the trace_syscall_exiting (to preserve the
>>> current output, which in my opinion is more user friendly).
>>> My was a dirty and bad work-around, I admit it.
>>>
>>>> ...However, I've found more important thing.
>>>> libunwind scans /proc/$pid/maps every print_stacktrace invocation!
>>>> If libunwind provides `unw_get_proc_name_and_path',
>>>> the map cache management will not be needed in strace.
>>>
>>> I noticed that. Honestly speaking, I was thinking to first get this
>>> patch in and then in a second step, try to code another patch which
>>> provides a custom get_dyn_info_list_addr call back [1] (which is where
>>> the scan of the maps is done).
>>> In the custom get_dyn_info_list_addr we can then use the info we
>>> already have in our mmap_cache.
>>> My first concern was to get the functionality in, then we can work on
>>> improving its performance.
>>>
>>> The problem is that libunwind will scan anyway maps every stack trace
>>> (aka every system call, that is performance killer), if you re-write
>>> get_dyn_info_list_addr to use our mmap_cache you can parse the maps
>>> file only when really needed and use the cache the other times.
>>>
>>
>> Hey Masatake,
>> Are you gonna send a patch to fix the map reloading even when using -e?
>>
>> I don't mean to hurry you, I was wondering how do you want to proceed.
>>
>> Sincerely,
>> Luca
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Strace-devel mailing list
> Strace-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel
More information about the Strace-devel
mailing list