Chris Quenelle wrote:
> > While doing some tests with ksh93 and "dbx" (Sun Studio 11) I found the
> > following issue ("bcheck -all" is the same as "dbx -check all" without
> > interactive prompting for each hit; ksh93 was built using
> > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/scripts/buildksh93.ksh):
> > -- snip --
> > % bcheck -all ./arch/sol10.sun4/bin/ksh
> > Reading ksh
> > Reading ld.so.1
> > Reading rtcapihook.so
> > Reading libm.so.2
> > Reading libsecdb.so.1
> > Reading libc.so.1
> > Reading libdl.so.1
> > Reading libnsl.so.1
> > Reading libcmd.so.1
> > Reading rtcaudit.so
> > Reading libmapmalloc.so.1
> > Reading libgen.so.1
> > Reading libc_psr.so.1
> > Reading rtcboot.so
> > Reading librtc.so
> > access checking - ON
> > memuse checking - ON
> > Running: ksh
> > (process id 24663)
> > RTC: Enabling Error Checking...
> > RTC: Using UltraSparc trap mechanism
> > RTC: See `help rtc showmap' and `help rtc limitations' for details.
> > RTC: Running program...
> > $
> > $ RTC: program wrote over private RTC data -- disabling Error Checking
> > file: memerror.c line: 297
> > -- snip --
> >
> > The problem here seems that the RTC subsystem is unable to track memory
> > allocations done by the vmalloc subsystem of libast (see
> > http://www.opensolaris.org/os/project/ksh93-integration/docs/ksh93r/man/man3/vmalloc/).
> >
> > The question is now how to fix that problem. rtc_api(3x) seems to
> > indicate that calls to allocations and deallocations need to be
> > "annouced" to the RTC subsystem via |_rtc_record_free()|,
> > |_rtc_record_malloc()| and |_rtc_record_realloc()|, however the
> > allocators in libc/watchmalloc/libmapmalloc/etc. do not seems to use
> > this API (= % nm /usr/lib/libmapmalloc.so | fgrep -i rtc # returns
> > nothing).
> >
> > The question is now: What's the right solution ? Should libast's vmalloc
> > call |_rtc_record*()| or does dbx need to be modified ? And why is this
> > mess needed - after all vmalloc seems to use |mmap()| - why isn't this
> > tracked automatically by dbx ?
>
> Tracking mmap isn't good enough. To collect stacks from the place an
> individual block is allocated you need hooks at that spot. Not
> the underlying large-scale system allocator.
Ok... what is the correct way to do that ? Add calls to
|_rtc_record_free()|, |_rtc_record_malloc()| and |_rtc_record_realloc()|
to the vmalloc allocator code (which again raises the question why
libumalloc in Solaris doesn't need that...) ?
> RTC doesn't work for all applications. It might not be suitable
> for ksh in this case. I wish it were otherwise.
Erm... that would be very very bad... as you know (or remember) there is
libshell.so which should be used in other parts of Solaris, too (usually
supersetting or replacing libtecla&co.) - and I am sure the people will
not be happy if "dbx -check access" results in something like "RTC:
program wrote over private RTC data -- disabling Error Checking" (e.g.
rendering this dbx functionality useless) ... ;-(
IMO this needs to be ASAP addressed somehow...
> There are several Sun Studio support forums on developers.sun.com.
> They are a good way of getting help specific to the Sun Studio tools.
Yes, but IMO it may be nice to keep the discussion here (that it gets
archived) ... unfortunately the support forums are no mailinglist (and
AFAIK provide no long-term archive) ... ;-(
> I have also cc:ed Leonard Li who is our RTC engineer.
Thanks! :-)
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
