help-bash
[Top][All Lists]
Advanced

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

Re: [Help-bash] Question: Capturing command output (on-screen keyword co


From: Matthew Giassa
Subject: Re: [Help-bash] Question: Capturing command output (on-screen keyword colorizer/prettifier).
Date: Wed, 05 Oct 2016 17:35:10 -0700
User-agent: Workspace Webmail 6.5.1

I managed to get 99% of the way there. I used dup()/pipe()/dup2() and
hooked fork() to redirect stdout for bash and child processes to a
dedicated per-process pipe. I then spawn a dedicated (detached) worker
thread after forking which reads in the pipe, and then sends it merrily
along to the PTS/TTY (doesn't yet inject color codes).

I've noticed the following undesired behavior though when I initially
start BASh:
Case 1:
    malloc: .././subst.c:8902: assertion botched
    free: start and end chunk sizes differ
    Aborting...
    malloc: unknown:0: assertion botched
    free: start and end chunk sizes differ
    Aborting...Aborted (core dumped)

Case 2:
    malloc: unknown:0: assertion botched
    malloc: block on free list clobbered
    Aborting...Aborted (core dumped)

Case 3:
    malloc: .././unwind_prot.c:320: assertion botched
    malloc: block on free list clobbered
    Aborting...
    malloc: .././array.c:93: assertion botched
    malloc: block on free list clobbered
    last command: (null)
    Aborting...Aborted (core dumped)

Case 4:
    malloc: .././dispose_cmd.c:249: assertion botched
    free: called with already freed block argument
    Aborting...Aborted (core dumped)


This issue occurs about 5% of the time (and will randomly be one of the
error cases shown above), and only occurs at initial BASh launch. Once
the shell is up and running, no stability issues arise.

What's really interesting about this is that I cannot get the issue to
occur if I launch BASh in GDB using my LD_PRELOAD'ed library, ever. I
setup a script to loop through the process thousands of times over the
past few errors, and the problems shown above never popped up once.

Are there environment variables or settings which BASh alters if it
detects it's being traced which could affect my GDB testing? I'd like to
track down the cause of this issue.

Thank you.


> -------- Original Message --------
> Subject: Re: [Help-bash] Question: Capturing command output (on-screen
> keyword colorizer/prettifier).
> From: Chet Ramey <address@hidden>
> Date: Wed, October 05, 2016 7:18 am
> To: Matthew Giassa <address@hidden>, address@hidden
> Cc: address@hidden
> 
> 
> On 10/4/16 9:20 PM, Matthew Giassa wrote:
> 
> > 
> >     While I'm able to get the output of echo commands, the PS1/PS2/etc
> > variables, and so on, I can't seem to get the output of the "ls" command
> > for
> > example. I've checked the symbols used to write data out to the console
> > via the
> > following: readelf --dyn-syms /bin/bash | grep -i -e write -e printf
> > 
> > Output:
> >      6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (5)
> >     13: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (5)
> >     39: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (2)
> >     98: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (8)
> >    142: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (5)
> >    152: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (5)
> >    191: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (2)
> >    192: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (5)
> >    213: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND
> > address@hidden (5)
> > 
> >     So as far as I can see, I'm hooking all of the typical commands BASh
> > would use to write to the console, yet there is still output which I'm
> > not
> > capturing.
> > 
> >     Is there yet another function BASh uses which I would need to hook in
> > order to capture all command output within the LD_PRELOAD'ed C library?
> 
> Since `ls' is a separate executable, it handles input and output itself.
> Bash doesn't get involved with it.
> 
> If you want to hook the separate child processes to your LD_PRELOAD
> library, you need to make sure that LD_PRELOAD survives the fork and
> is available to the loader.  That might be as simple as exporting the
> variable.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]