dbaccess segfaults when username not "informix"

I've installed IDS 7.3UC7 under Red Hat Linux 5.2 (2.0 kernel). It works fine when I use dbaccess to connect as the "informix" username but trying to connect as any other username just makes dbaccess seg fault and core dump. This is at the stage where you choose a database (either explicitly via the Database/Select menu or implicitly via Query-Language/Select database). I get Running . . .Segmentation fault (core dumped) and strace and gdb don't give me any clues either. I have the following environment variables set (both as user informix and my ordinary username): INFORMIXDIR=/opt/informix INFORMIXSERVER=plutonium_shm The same behaviour occurs if I choose INFORMIXSERVER plutionium (i.e. works fine for informix username, core dumps for my own). Attempting to build DBD::Informix (the DBI backend module for Perl) leads to a similar core dump when it tries out its very basic ESQL program so I doubt it's a problem with dbaccess itself. /opt/informix/etc/sqlhosts contains: plutonium_shm onipcshm host_dontcare plutonium_shm plutonium onsoctcp plutonium 1234 /opt/informix/etc/onconfig contains the following (I've pruned out groups of entries which I haven't changed): ROOTNAME rootdbs # Root dbspace nameROOTPATH /var/lib/informix/rootdbs ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) ROOTSIZE 20000 # Size of root dbspace (Kbytes)MIRROR 0 # Mirroring flag (Yes = 1, No = 0) MIRRORPATH # Path for device containing mirrored root MIRROROFFSET 0 # Offset into mirrored device (Kbytes)PHYSDBS rootdbs # Location (dbspace) of physical log PHYSFILE 1000 # Physical log file size (Kbytes) LOGFILES 6 # Number of logical log files LOGSIZE 500 # Logical log size (Kbytes)MSGPATH /var/log/informix/online.log # System message log file path CONSOLE /dev/console # System console message path ALARMPROGRAM /opt/informix/etc/log_full.sh # Alarm program pathSYSALARMPROGRAM /opt/informix/etc/evidence.sh # System Alarm program path TBLSPACE_STATS 1 TAPEDEV /dev/null # Tape device path TAPEBLK 16 # Tape block size (Kbytes) TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes) LTAPEDEV /dev/null # Log tape device path LTAPEBLK 16 # Log tape block size (Kbytes) LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes)STAGEBLOB # Informix Dynamic Server/Optical staging area SERVERNUM 1 # Unique id corresponding to a Dynamic Server in DBSERVERNAME plutonium # Name of default database server DBSERVERALIASES plutonium_shm # List of alternate dbservernames DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. RESIDENT 0 # Forced residency flag (Yes = 1, No = 0) MULTIPROCESSOR 0 # 0 for single-processor, 1 for multi-processor NUMCPUVPS 1 # Number of user (cpu) vps SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors LOCKS 2000 # Maximum number of locks BUFFERS 200 # Maximum number of shared buffers NUMAIOVPS # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 6 # Maximum number of logical log files CLEANERS 1 # Number of buffer cleaner processes DBSPACETEMP # Default temp dbspaces DUMPDIR /tmp # Preserve diagnostics in this directory DUMPSHMEM 1 # Dump a copy of shared memory DUMPGCORE 0 # Dump a core image using 'gcore' DUMPCORE 0 # Dump a core image (Warning:this aborts Dynamic DUMPCNT 1 # Number of shared memory or gcore dumps for FILLFACTOR 90 # Fill factor for building indexes USEOSTIME 0 # 0: use internal time(fast), 1: get time from O DATASKIP off # List of dbspaces to skip I'm only just starting to look into Informix so it may easily be something obvious I've missed. Having subscribed to this newsgroup and scanned a couple of thousand articles, I don't *think* I've done anything embarrassingly stupid and I think I've provided here the information that's usually asked for. Can anyone help, please? --Malcolm -- Malcolm Beattie <mbeattie@sable.ox.ac.uk> Oxford University Computing Services "I permitted that as a demonstration of futility" --Grey Roger

Malcolm Beattie wrote: > > I've installed IDS 7.3UC7 under Red Hat Linux 5.2 (2.0 kernel). It > works fine when I use dbaccess to connect as the "informix" username > but trying to connect as any other username just makes dbaccess seg > fault and core dump. This is at the stage where you choose a database > (either explicitly via the Database/Select menu or implicitly via > Query-Language/Select database). I get > Running . . .Segmentation fault (core dumped) > and strace and gdb don't give me any clues either. I have the > following environment variables set (both as user informix and my > ordinary username): > > INFORMIXDIR=/opt/informix > INFORMIXSERVER=plutonium_shm> > The same behaviour occurs if I choose INFORMIXSERVER plutionium > (i.e. works fine for informix username, core dumps for my own). > Attempting to build DBD::Informix (the DBI backend module for Perl) > leads to a similar core dump when it tries out its very basic ESQL > program so I doubt it's a problem with dbaccess itself. I tested this on RedHat 6.0 (kernel 2.2.5) and have definitely had no problems. I've not tested it on my RH 5.2 box because it isn't conveniently hooked into the network (it uses the same name and i/p address as my nice big RH 6.0 machine). So, you may be correct on RH 5.2, though it would be surprising. That the ESQL/C programs also crash is probably suggestive, but I don't know what it is suggesting. It might be worth validating the installation, to ensure that all the permissions are correct. But I don't see why that would give you core dumps. There's a set of tools at the IIUG web site (utils_jl) which include permission checking and setting scripts. -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>