[PATCH resend v2 2/3] makedumpfile: make the incomplete dumpfile generated by ENOSPC error analyzable

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>On 10/08/2014 01:39 PM, Atsushi Kumagai wrote:
>>> Since the incomplete dumpfile generated by ENOSPC error can't be anylyzed
>>> by crash utility, but sometimes this file may contain important information
>>> and the panic problem won't be reproduced, then we came up with an idea to
>>> modify the exist data of the incomplete dumpfile to make it analyzable by
>>> crash utility. And each of those dumpfiles has a flag to indicate that it
>>> has been modified. As there are two formats of these dumpfiles, different
>>> methods and flags are needed to deal with each of them,
>>>
>>> elf:
>>> Modify the value of the PT_LOAD program header to reflect the actual size
>>> of the incomplete dumpfile. This method can't be used to modify the dumpfile
>>> written in flattened mode. This format use the "e_flags" of "elf header"
>>> to indicate that it has been modified.
>>
>> Is it necessary to change the PT_LOAD headers in makedumpfile ?
>> It sounds too much work for makedumpfile, I think it's better to
>> avoid such an irreversible and more than enough change in capturing
>> phase. Are there some reasons why you don't do the same thing on the
>> fly in crash ?
>>
>> OTOH, setting the incomplete flag is certainly makedumpfile's task
>> since crash can't detect ENOSPC.
>>
>>
>> Thanks
>> Atsushi Kumagai
>
>hello
>
>Actually, it just change the attribute:FileSiz of the PT_LOAD header
>having incomplete segment. The attribute shows the size of the segment
>in elf file. Because of that, crash can read the file correctly. And we
>haven't found it have anything to do with the original information so
>far,the information before makedumpfile. So, modifying header won't
>change too much data and won't lose any important information.
>
>However, though it can be done in crash, the process will be much more
>complicated. I think it's not worth to do this just for that useless data.

Can't you do just the same thing in crash when the incomplete flag is found ?

>If you think it is really needed, I will do that later.

Ideally, it's best to keep original data as much as possible, but
I'll accept this patches if the implementation for crash has to
be too complicated.


Thanks
Atsushi Kumagai


[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux