Writing your own shell… stuck on pipes?

I spent several hours nail down how to do pipe if you are writing your own shell. Most of the online reference is focusing 2 commands only. Here is the example of having 3 commands pipe together: ls -al | sort | cat -n

#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

static const int PIPE_READ = 0;
static const int PIPE_WRITE = 1;

int main(int argc, char **argv)
{
    int status;
    int fd[2];
    pid_t pid;

    pid = fork();
    if (pid == 0) {

        pipe(fd);
        if (fork() == 0) {
            dup2(fd[PIPE_WRITE], STDOUT_FILENO);
            close(fd[PIPE_READ]);
            close(fd[PIPE_WRITE]);

            pipe(fd);
            if (fork() == 0) {
                dup2(fd[PIPE_WRITE], STDOUT_FILENO);
                close(fd[PIPE_READ]);
                close(fd[PIPE_WRITE]);
                execlp("ls", "ls", "-la", NULL);
            } else {
                dup2(fd[PIPE_READ], STDIN_FILENO);
                close(fd[PIPE_WRITE]);
                close(fd[PIPE_READ]);
            }

            execlp("sort", "sort", NULL);
        } else {
            dup2(fd[PIPE_READ], STDIN_FILENO);
            close(fd[PIPE_WRITE]);
            close(fd[PIPE_READ]);
        }

        /* IMPORTANT: don't add any wait/waitpid here */
        //waitpid(pid2, &status, 0);

        execlp("cat", "cat", "-n", NULL);
    }
    waitpid(pid, &status, 0);
    return EXIT_SUCCESS;
}

You can easily refactor this to a recursive function. Pay attention to not have the waitpid/wait() at the first and second command, or your child processes will block at wait.

Java thread stalls in Solaris x86 VM

Just found out this thread in which it definitely helped us on solving some problems with the unit test failure/timeout in Java.

curl error 2: Failed to initialize the curl handle in windows 2003

If you have same problem in a chinese windows 2003, it may be related to the same reason that I have seen. Check if the DNS entry in TCP/IP properties windows is empty. The machine that we had a problem had set the IP to be static and leave the DNS entry empty while it's not automatic DNS.

Java Hotspot JVM crashes in Windows/Solaris-SPARC: libjvm.so GenCollectForAllocation SIGSEGV UseAdaptiveSizePolicy UseConcMarkSweepGC

Yesterday it seemed I encounter a bug in the new garbage collector of Hotspot JVM version 14+. Basically the application crashed during the startup, the platform was solaris 9 and windows 2003 r2.

The hs_err_pid reported to us:

#  SIGSEGV (0xb) at pc=0xfe847fc0, pid=9196, tid=6
#
# JRE version: 6.0_18-b07
# Java VM: Java HotSpot(TM) Server VM (16.0-b13 mixed mode solaris-sparc )
# Problematic frame:
# V  [libjvm.so+0x447fc0]
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00125400):  VMThread [stack: 0xd7980000,0xd7a00000] [id=6]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), si_addr=0xfbe88fc6

Registers:
 O0=0x0006ffe8 O1=0xf8616088 O2=0x00000000 O3=0x00000000
 O4=0x00000000 O5=0x00000000 O6=0xd79ff108 O7=0x00000000
 G1=0xfee56000 G2=0xfee39800 G3=0xf7c2c258 G4=0xd79ff5b0
 G5=0xd9c00000 G6=0x00000000 G7=0xff330a00 Y=0x00000000
 PC=0xfe847fc0 nPC=0xfe847fc4


Top of Stack: (sp=0xd79ff108)
0xd79ff108:   fe7f7fcc fee2622c d7c00000 000361d8
0xd79ff118:   fee3d000 fbc00000 24000000 09000000
0xd79ff128:   d79ff59c fb7c2000 006c6fc6 00000011
0xd79ff138:   00038d98 00034d08 d79ff168 feb66578
0xd79ff148:   00000000 00000000 00000000 00000000
0xd79ff158:   00000000 00000009 d9c11abb 00000000
0xd79ff168:   fee39ac4 fee560c8 00122260 00000008
0xd79ff178:   00000032 00000033 d8df8dd4 d8dcf9d8 

Instructions: (pc=0xfe847fc0)
0xfe847fb0:   fa 06 20 10 b6 10 20 11 f8 07 60 08 f2 07 20 4c
0xfe847fc0:   f6 2e 40 1a 81 c7 e0 08 81 e8 20 00 9d e3 bf a0 

Stack: [0xd7980000,0xd7a00000],  sp=0xd79ff108,  free space=1fcfe847fc0k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x447fc0]
V  [libjvm.so+0x766580]
V  [libjvm.so+0x766dc8]
V  [libjvm.so+0x765b5c]
V  [libjvm.so+0x73b1a0]
V  [libjvm.so+0x4b8048]
V  [libjvm.so+0x3ff9b0]
V  [libjvm.so+0x84cb38]
V  [libjvm.so+0x1e002c]
V  [libjvm.so+0x84f7bc]
V  [libjvm.so+0x84fd54]
V  [libjvm.so+0x25f7e0]
V  [libjvm.so+0x728448]

VM_Operation (0xd5b3bf2c): GenCollectForAllocation, mode: safepoint, requested by thread 0x006e3c00
...
VM Arguments:
jvm_args: -ea -Djava.io.tmpdir=tmp -Dcom.sun.management.jmxremote -Xss256k -XX:+UseAdaptiveSizePolicy -XX:+UseConcMarkSweepGC -Djava.awt.headless=true -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 ...
...
Signal Handlers:
SIGSEGV: [libjvm.so+0x84c6bc], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGBUS: [libjvm.so+0x84c6bc], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGFPE: [libjvm.so+0x1c0168], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGPIPE: [libjvm.so+0x1c0168], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGXFSZ: [libjvm.so+0x1c0168], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGILL: [libjvm.so+0x1c0168], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGQUIT: [libjvm.so+0x72abdc], sa_mask[0]=0x7fbffeff, sa_flags=0x00000004
SIGHUP: [libwrapper-solaris-sparc-32.so+0x23b8], sa_mask[0]=0x00000000, sa_flags=0x00000012
SIGINT: [libwrapper-solaris-sparc-32.so+0x2378], sa_mask[0]=0x00000000, sa_flags=0x00000012
SIGTERM: [libwrapper-solaris-sparc-32.so+0x2398], sa_mask[0]=0x00000000, sa_flags=0x00000012
SIG39: [libjvm.so+0x72e608], sa_mask[0]=0x00000000, sa_flags=0x00000008
SIG40: [libjvm.so+0x1c0168], sa_mask[0]=0x7fbffeff, sa_flags=0x0000000c


---------------  S Y S T E M  ---------------

OS:                        Solaris 9 9/04 s9s_u7wos_09 SPARC
           Copyright 2004 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 29 June 2004

uname:SunOS 5.9 Generic_117171-07 sun4u  (T2 libthread)
rlimit: STACK 8192k, CORE infinity, NOFILE 4096, AS infinity
load average:1.08 0.42 0.26

CPU:total 2 has_v8, has_v9, has_vis1, has_vis2, is_ultra3

Memory: 8k page, physical 2097152k(1453840k free)

vm_info: Java HotSpot(TM) Server VM (16.0-b13) for solaris-sparc JRE (1.6.0_18-b07), built on Dec 17 2009 14:12:56 by "" with Workshop 5.8

time: Tue Feb 16 10:42:22 2010
elapsed time: 7 seconds

I have googled a lot of pages and no luck. I thought it's related to whether my solaris was not updated enough. My HelloWorld can be run without any problem as well. Therefore, I was thinking maybe it's related to the garbage collector somehow due to the word "collect" in GenCollectForAllocation.

From the vm arguments above, you could see it's using -XX:+UseAdaptiveSizePolicy and actually this argument should be an no-op according to here. Once I removed it, everything works fine now.

So, maybe there is a bug in having UseAdaptiveSizePolicy and UseConcMarkSweepGC crashing the windows/solaris latest hotspot JVMs.

GWT: java.lang.UnsatisfiedLinkError: com.google.gwt.user.client.Random.nextDouble()

Just started learning GWT, and running through the tutorials. The first error I encountered is java.lang.UnsatisfiedLinkError: com.google.gwt.user.client.Random.nextDouble() when running the example. The reason is listed here and here. The reason I posted this blog entry is that, searching the exact string of my title in google yielded nothing. The reason may be that people had problems in nextInt more often.