Re: fcore status

[Phil Muldoon <pmuldoon at redhat dot com>]

> Phil, I notice one issue. In gdb, one map whose is unwritable won't be
> dumped out by gcore. However, in our fcore, it is dumped out. I'm not
> sure whether we should rethink of this. 
>
> On one hand, if one map unwritable is dumped out, it will make the core
> file larger. In gdb, it consider the map unwritable can be got from the
> executable program in disk, which is the reason why gcore doesn't dump
> out such kind of maps. For some application with large size, this will
> dump out a large core file! 
>   
> On the other hand, if we dump out all entries in /proc/self/maps, we
> maybe do more things on core file debugging than that gdb can do(now, we
> must use gdb like this for core file debugging: gdb executable-file
> core-file. And under such a circumstance we can't input step/next
> commands. If we dump all, we maybe provide support for running step/next
> commands in core file debugging. But it's just maybe.)
>   

Right now fcore dumps out all maps it can ( this is for debugging more 
than practice) and we can easily tweak what maps to dump in the future 
by adjusting CoreMapsBuilder. It's just a matter of reading the flags 
really, and deciding on a map by map basis.
> So what should we choose, dump out one map unwritable or not?
>   

I think ultimately we should only dump out maps that are only writable, 
but to change it one way or the other is just an additional if () 
condition, so very easy to alter.
>   
> > Caveats:
> >
> > - MapsBuilder seems to sometimes not produce complete map tables from /proc/$$/map
> >     
>
> Some items in maps table are filtered out! Those items who are unreadable won't be built, such as 
> [vdso] item in /proc/self/maps. So sometimes you will get one uncomplete map tables. But this doesn't matter.
>   

It seems worse than that. If you dump gedit, there are a lot of maps 
that we never see (resulting in a large core file for gcore,  and a much 
much smaller one for fcore). I'm still not sure where this problem is 
yet, of if it even is a problem.
>   
> > - I suspect as mixing ints (byte[] arrays size) with long (MapsBuilder api), with ints (inua.eio.ByteBuffer get parameters), we will smash on huge core files.
> >     
> If you can detail this, it's very appreciated!
>   
I'm not sure if this will be an issue, need to talk to Andrew. On a 
large scale architecture, if the core file map > byte[int] max then it 
might be an issue.

> > - Task.getMemory() only seems to map up the maximum for 32 bit architectures?
> >     
> I also notice this. But in PtraceByteBuffer.cxx, there's some comments about "maxOffset". The maxOffset isnot
> checked in ByteBuffer interface. So it won't bring trouble to us now. 
>
> Phil, we should add some new class for arch-dependent operations on ELF header and PT_NOTE dumping out. I hope I can post one
> patches and have some discussion based on it.
>   

I do all my operations on the header via gelf which is arch dependent, 
so we are arch dependent on all elf operations?

Yes, I totally agree on PT_NOTE arch dependent information if that is 
what you mean.

Regards

Phil