Gdb 6.2.1 in Solaris 10

I am not able to debug using gdb in solaris 10
following error i get.
bash-3.00$
bash-3.00$ gdb ./EAPAppln
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10"...
dwarf2-frame.c:1071: internal-error: Unsupported encoding: DW_EH_PE_indirect
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
What to do???
Thanks
Pradeep Padhi

I'ld upgrade to the latest GDB, which is version 6.5.
7/M.

Similar Messages

Dbx uses 6GB (and counting) loading core file

I'm trying to load a core file in dbx, but it just keeps using memory (I killed it after 6GB resident size). It sits at the prompt
Reading conv
where conv is the executable.
The core file is 4.5M in size, the executable is 680kB. The program was compiled with gcc 3.4 as a 64-bit binary with debugging symbols - should dbx be able to load that? I've tried gdb from the sun.com Solaris Freeware page, however that seems unable to handle 64-bit programs.
We're running on Solaris 10, using dbx 7.5 2005/10/13 from Sun Studio 11.

Some questions:
- what happens if you just debug the executable w/o a corefile?
- Is the 680kB executable size a "text" size or "ls" size?
- Is your gcc producing stabs or DWARF?

Netbeans 6.1 C++ / SunStudio12 compiler / Solaris 10 - can I use GDB?

Hello,
My team dev stack is Solaris 10 and compilers that come with SunStudio12 (latest patches installed). We have been evaluating Netbeans 6.1 and it runs really nice. We like features, we like performance.
Now, can we use DBX in Netbean6.1 (C++ module) or even better, can we use GDB to debug binaries made with SS12 compiler?
I was looking for an answer on the forum but I'm confused. Can sb clarify this for me?
Thanks a lot!
Regards,
Przemyslaw Owczarek
Programmer / Analyst
Sabre Airline Products & Services

Some facts, not in any particular order.
- A version of sunstudio which runs on NB 6.0 has been available since Feb.
See the sticky articles at the beginning of this forum.
- NB 6.1 C++ pack only works with gdb.
- You can try gdb with sunstudio12 compilers but it's unlikely to work
well since debuggers and compilers work best when used as a matched pair.
- A sunstudio based on NB6.1 will be available sometime in the early summer.

Is there a 64-bit gdb for Solaris (I need both x86 and Sparc)

I'm looking for publicly available versions of gdb for both SPARC and Intel. I'm the current
developer of the NetBeans gdb module and we've had bugs filed that our Solaris users
can't debug 64-bit applications.
I've built a 64-bit gdb but its trying to dynamicly load a 32-bit .so (libexpat.so.0). I can still
run it by setting LD_LIBRARY_PATH, but can't figure out how to configure my gdb build
to use the right libexpat. Even if I could, I need something like the companion CD or
sunfreeware.com to provide (I'd even settle for gdb.gnu.org:-)
If anyone knows of publicly available versions, please email me.
Thanks,
Gordon

Again, I think you need to check the Microsoft web page, as I was able to find 64 bit versions of IE8 for download.
The URL to access the page is
http://windows.microsoft.com/en-US/internet-explorer/downloads/ie-8
From that page, I am able to select a 64 bit version of IE 8 for the following Operating Systems
-- Windows XP 64 Bit
-- Windows Vista 64 Bit
-- Windows Server 2003 64 Bit
-- Windows Server 2008 64 Bit
Windows 7 is not listed as an option as it already comes with IE8 installed by default.
Looks to me that Microsoft has already released a 64 bit version of IE8.
In fact, I went ahead and downloaded IE8 for Windows 2003 Server x64 bit, and looked at the details of the file. Each microsoft download has a digital signature associated with them, showing a date and time of when the exe was built.
According to what is shown below, IE8 for Windows Server 2003 has been around since Sunday, March 08, 2009.
So, what has adobe been doing since March of 2009? IE8 has been 64 bit for well over 2 years now (it will be 3 in March of 2012). While I know that it does take time to develop new applications, I don't think it would take 3 years for Adobe to come up with a 64 bit version of Reader that could have been built under the 64 bit platform.
--Brian

Solaris 8 : core in /usr/lib/libssasnmp.so.1

Hello,
I have a core file when i use the trap_send_with_more_para() function to send a ColdStart trap in Solaris 8 (with or without the last SNMP patch (108869-18)) with SEA 1.0.3..
I have the same problem in Solaris 7 (SEA 1.0.3) when i add the 107709-20 patch.
I have no problem in Solaris 7 without the previous patch....
Thanks for your help.....
The gdb result is :
Core was generated by `snmpcd -s -d 0 -p 33045'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libsocket.so.1...done.
Reading symbols from /usr/lib/libnsl.so.1...done.
Reading symbols from /usr/lib/liby.so.1...done.
Reading symbols from /usr/lib/libl.so.1...done.
Reading symbols from /usr/lib/libelf.so.1...done.
Reading symbols from /usr/lib/libw.so.1...
warning: Lowest section in /usr/lib/libw.so.1 is .hash at 0x74
done.
Reading symbols from /usr/lib/libgen.so.1...done.
Reading symbols from /usr/lib/librt.so.1...done.
Reading symbols from /usr/lib/libssagent.so.1...done.
Reading symbols from /usr/lib/libssasnmp.so.1...done.
Reading symbols from /usr/lib/libc.so.1...done.
Reading symbols from /usr/lib/libdl.so.1...done.
Reading symbols from /usr/lib/libmp.so.2...done.
Reading symbols from /usr/lib/libaio.so.1...done.
Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1...done.
#0 0xff189b34 in trap_send_raw () from /usr/lib/libssasnmp.so.1
(gdb) bt
#0 0xff189b34 in trap_send_raw () from /usr/lib/libssasnmp.so.1
#1 0xff189e60 in trap_send_with_more_para () from /usr/lib/libssasnmp.so.1
#2 0x144d4 in SnmpcSendColdStart () at /home/vat/src/snmpc_appl.c:173
#3 0x14588 in agent_init () at /home/vat/src/snmpc_appl.c:210
#4 0xff1c8d34 in sap_main () from /usr/lib/libssagent.so.1
#5 0x14c84 in main (argc=5, argv=0xffbef7c4) at /home/vat/src/snmpc_appl.c:538
(gdb) q

You probably need to get the current SUNWlibC and Solaris thread library patches for the version of Solaris you are using.
You can find the latest compiler product patches at http://access1.sun.com/sundev/
You can find Solaris patches at http://sunsolve.sun.com/

GCC On Solaris 2.4

Hello Gents,
I'm trying to use the gnu c compiler in a Box with Solaris 2.4 but I've got this message when I try to compile something, also I've got a error message when I'm tryin' to generate the make files for specific program, in this case I'm talking about sudo, but this happens with any kind of software that I need to compile.
Can anyone tell me if I'd need to install another kind of patch or library to fix it?
# pkginfo | grep -i gcc
utility GNUgcc GNU gcc 2.95.2 SPARC Solaris 2.4
application SMClibgcc lgcc
# pkginfo | grep -v SUNW
utility GNUaconf GNU autoconf 2.13 SPARC Solaris 2.4
utility GNUamake GNU automake 1.4 SPARC Solaris 2.4
utility GNUgcc GNU gcc 2.95.2 SPARC Solaris 2.4
utility GNUgdb GNU gdb 4.17 SPARC Solaris 2.4
utility GNUgdbm GNU gdbm 1.8.0 SPARC Solaris 2.4
utility GNUmake GNU make 3.78.1 SPARC Solaris 2.4
application SMClibgcc lgcc
# cat nada.c
"nada.c" 11 lines, 97 characters
#include <stdio.h>
main()
for(;;)
printf ("Hello World!\n");
# /usr/local/bin/gcc nada.c -o nada
In file included from nada.c:1:
/usr/local/lib/gcc-lib/sparc-sun-solaris2.4/2.95.2/include/stdio.h:17: sys/featu
# cd /sudo-1.6.9p16
# ./configure
configure: Configuring Sudo version 1.6.9
checking whether to lecture users the first time they run sudo... yes
checking whether sudo should log via syslog or to a file by default... syslog
checking which syslog facility sudo should log with... local2
checking at which syslog priority to log commands... notice
checking at which syslog priority to log failures... alert
checking how long a line in the log file should be... 80
checking whether sudo should ignore '.' or '' in $PATH... no
checking whether to send mail when a user is not in sudoers... yes
checking whether to send mail when user listed but not for this host... no
checking whether to send mail when a user tries a disallowed command... no
checking who should get the mail that sudo sends... root
checking for bad password prompt... Password:
checking for bad password message... Sorry, try again.
checking whether to expect fully qualified hosts in sudoers... no
checking for umask programs should be run with... 0022
checking for default user to run commands as... root
checking for editor that visudo should use... vi
checking whether to obey EDITOR and VISUAL environment variables... no
checking number of tries a user gets to enter their password... 3
checking time in minutes after which sudo will ask for a password again... 5
checking time in minutes after the password prompt will time out... 5
checking whether to use per-tty ticket files... no
checking whether to include insults... no
checking whether to override the user's path... no
checking whether to get ip addresses from the network interfaces... yes
checking whether stow should be used... no
checking whether to do user authentication by default... yes
checking whether to disable running the mailer as root... no
checking whether to disable shadow password support... no
checking whether root should be allowed to use sudo... yes
checking whether to log the hostname in the log file... no
checking whether to invoke a shell if sudo is given no arguments... no
checking whether to set $HOME to target user in shell mode... no
checking whether to disable 'command not found' messages... no
checking for egrep... egrep
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
#

I found the solution myself and will shortly summarize it here to complete the thread.
(1) Use GNU as and non-GNU ld, so add "--with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld" to the configure command line. After I worked this out I found it noted on the build instruction website, RTFM proved to be useful again. :-)
(2) At some point the compilation aborted because directory stage3-gcc could not be found, so I had to do "ln -s stage3-i386-pc-solaris2.10 stage3-gcc". Maybe this can be avoided with some other configure options, but this workaround was fine for me.
(3) In order to use my own versions of gmp and mpfr, I had to add their library directory to the LD_LIBRARY_PATH environment variable (--with-gmp= and --with-mpfr= are not sufficient).
Kind regards,
Christian

JVM crash for weblogic8.1 running on solaris and JDK1.4.2_05

Hi,
I am an administrator of weblogic8.1 server platfrom running solaris8.1 There are 2 managed server runs on 2 solaris unix box and admin server run on a third solaris unix box. Since last couple of days, weblogic server crashing everyday creating a core file and hs_err_pidxxxx.log, on each manage server.Below is the content of hs_err_pidxxxx.log.
Unexpected Signal : 11 occurred at PC=0xFE1CBCAC
Function=[Unknown. Nearest: JVM_FillInStackTrace+0x4CE4]
Library=/bea/jdk142_05/jre/lib/sparc/server/libjvm.so
Current Java thread:
Dynamic libraries:
0x10000 /bea/jdk142_05/bin/java
0xff360000 /usr/lib/libthread.so.1
0xff3a0000 /usr/lib/libdl.so.1
0xff200000 /usr/lib/libc.so.1
0xff340000 /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
0xfe000000 /bea/jdk142_05/jre/lib/sparc/server/libjvm.so
0xff2e0000 /usr/lib/libCrun.so.1
0xff1e0000 /usr/lib/libsocket.so.1
0xff100000 /usr/lib/libnsl.so.1
0xff0d0000 /usr/lib/libm.so.1
0xff1c0000 /usr/lib/libsched.so.1
0xff310000 /usr/lib/libw.so.1
0xff0a0000 /usr/lib/libmp.so.2
0xff070000 /bea/jdk142_05/jre/lib/sparc/native_threads/libhpi.so
0xff050000 /usr/lib/nss_files.so.1
0xfe7d0000 /bea/jdk142_05/jre/lib/sparc/libverify.so
0xfe790000 /bea/jdk142_05/jre/lib/sparc/libjava.so
0xfe770000 /bea/jdk142_05/jre/lib/sparc/libzip.so
0xf94a0000 /osmf/i3/i3v7/products/j2ee/lib/libPreciseLog.so
0xf9480000 /usr/lib/libpthread.so.1
0xf9460000 /usr/lib/libkstat.so.1
0xa9050000 /bea/jdk142_05/jre/lib/sparc/libnet.so
0xa9290000 /usr/lib/nss_dns.so.1
0xa8db0000 /usr/lib/libresolv.so.2
0xa9030000 /bea/weblogic814/server/lib/solaris/libmuxer.so
0xa8b60000 /usr/ucblib/libucb.so.1
0xa8b20000 /usr/lib/libelf.so.1
0xa8d90000 /bea/jdk142_05/jre/lib/sparc/libnio.so
0xa8a60000 /usr/lib/librt.so.1
0xa8920000 /usr/lib/libaio.so.1
0xa8900000 /usr/lib/libsendfile.so.1
0xa83e0000 /bea/jdk142_05/jre/lib/sparc/libioser12.so
Heap at VM Abort:
Heap
def new generation total 339264K, used 293091K [0xa9400000, 0xbe950000, 0xbe950000)
eden space 329024K, 87% used [0xa9400000, 0xbac61f00, 0xbd550000)
from space 10240K, 58% used [0xbd550000, 0xbdb26ea0, 0xbdf50000)
to space 10240K, 0% used [0xbdf50000, 0xbdf50000, 0xbe950000)
tenured generation total 699072K, used 204153K [0xbe950000, 0xe9400000, 0xe9400000)
the space 699072K, 29% used [0xbe950000, 0xcb0ae7f8, 0xcb0ae800, 0xe9400000)
compacting perm gen total 65024K, used 64974K [0xe9400000, 0xed380000, 0xf9400000)
the space 65024K, 99% used [0xe9400000, 0xed373a30, 0xed373c00, 0xed380000)
Local Time = Mon Nov 20 13:17:55 2006
Elapsed Time = 150397
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002EF 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
# Java VM: Java HotSpot(TM) Server VM (1.4.2_05-b04 mixed mode)
any idea?

Hi Jitesh
JVM crash could be because of any code, it could be weblogic or your own application or a bug in JDK itself.
1) You can run tools like GDB on the core file which will indicate the source of the crash.
From the stack it looks like a Sun JDK bug
2) Search on sun for this error code shows some known bugs. Checkout http://onesearch.sun.com/search/onesearch/index.jsp?charset=utf-8&col=developer-debugging&qt=4F530E43505002EF+01&rt=true&cs=false
3) You can also upgrade the JVM to the latest version of 1.4.2. I believe you have 1.4.2_05
Vimala-

Core dump before entering main in Solaris 5.7 using SunWS 5.3 compiler

Hi ..
I have a test program which links with one of our libraries. Both have been built using SunWS 5.3 compiler on Solaris 5.7 machine.
CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-19 2003/12/18
This test application cores even before it enters main(). The gdb stack trace is as follows :
#0 0xfeff9e94 in __sigprocmask ()
#1 0xfefef3f4 in _resetsig ()
#2 0xfefeebb0 in _sigon ()
#3 0xfeff19a0 in thrpkill ()
#4 0xff1b95a8 in abort ()
#5 0xff2741e8 in void __Cimpl::ex_terminate() ()
#6 0xff274c28 in exthrow_body ()
#7 0xff358478 in void std::locale::init() ()
#8 0x4363c in std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::basic_streambuf #Nvariant 1() ()
#9 0x416c8 in std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::basic_filebuf(int) ()
#10 0x3ae48 in std::__Wide_Init::__Wide_Init() ()
#11 0x3b044 in __SUNW_init_wiostreams ()
#12 0xff276364 in void __Cimpl::cplus_init() ()
#13 0xff277e18 in __cplus_fini_at_exit ()
#14 0xff3bcff0 in ?? ()
#15 0xff3bc764 in ?? ()
#16 0xff3c80c4 in ?? ()
#17 0xff3b2bf4 in ?? ()
The dbx stack trace is :
current thread: t@1
=>[1] __sigprocmask(0x0, 0xffbef098, 0x0, 0xffffffff, 0xffffffff, 0x0), at 0xfeff9e94
[2] _resetsig(0xff00cb24, 0x0, 0x0, 0x0, 0x8ac14, 0x8ac18), at 0xfefef3ec
[3] _sigon(0xff014458, 0xff014438, 0x8ac10, 0xffbef16c, 0x6, 0xff1ce178), at 0xfefeeba8
[4] thrpkill(0x0, 0x1, 0x6, 0xff00cb24, 0x8ab98, 0xff274818), at 0xfeff1998
[5] abort(0xff235f84, 0x0, 0xff3b2c28, 0x15888, 0x14620, 0xff2743b8), at 0xff1b95a0
[6] __Cimpl::ex_terminate(0x0, 0xff358538, 0xff28a940, 0xff3939a0, 0x3760c, 0x1), at 0xff2741e0
---- hidden frames, use 'where -h' to see them all ----
[8] std::locale::init(0x0, 0x0, 0xff00cb24, 0x0, 0x0, 0x2a8), at 0xff358470
[9] std::basic_streambuf<wchar_t,std::char_traits<wchar_t> >::basic_streambuf(0x86a60, 0x42b7c, 0x0, 0x0, 0x7c, 0x84218), at 0x43634
[10] std::basic_filebuf<wchar_t,std::char_traits<wchar_t> >::basic_filebuf(0x86a60, 0x0, 0x0, 0x4943c, 0x0, 0x0), at 0x416c0
[11] std::__Wide_Init::__Wide_Init(0x86ba8, 0x1, 0x0, 0x0, 0x0, 0x0), at 0x3ae40
[12] __SUNW_init_wiostreams(0xff394214, 0x3b030, 0xffffffff, 0xff394210, 0xff28a08c, 0xff28a820), at 0x3b03c
[13] __Cimpl::cplus_init(0x0, 0x0, 0x15bb8, 0xfeff68f8, 0xff28a748, 0xfffed858), at 0xff27635c
[14] 0xff277e10(0x0, 0xff3e6a8c, 0xff3e7004, 0xff3e7004, 0xff3e7004, 0xff3bcfe0), at 0xff277e0f
[15] call_init(0xff3e86c8, 0xff3e6aa8, 0xff3e6b7c, 0x200000, 0xfefd154c, 0xfefd1548), at 0xff3bcfe8
[16] setup(0xff3e8a70, 0xff3e6a10, 0x0, 0xff3e6aa8, 0x84890, 0x10074), at 0xff3bc75c
[17] _setup(0xff3b2774, 0x202, 0x300, 0xffffffff, 0xffffffff, 0xff3b0000), at 0xff3c80bc
[18] rtboot(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff3b2bec
Interestingly, if I compile the same code on a Sun 5.6 machine with the same 5.3 compiler (CC: Sun WorkShop 6 update 2 C++ 5.3 2001/05/15), there is no core.
Looks like some global object is creating a problem since it is coring before entering main itself.
Does anybody have an idea of what is the problem ? Do I have to install any patch for this ?
Thanks in advance.
Ganesh

Hi Stephen ..
Thanks for your reply. I will definitely try what you suggested. But why does this work correctly when I build the library (.so) in Sun 5.6 and build the executable in 5.7 ??
Here are the ldd outputs for the library after being built on 5.6 and 5.7 respectively.
On 5.6 :
libc.so.1 => /usr/lib/libc.so.1
libposix4.so.1 => /usr/lib/libposix4.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libaio.so.1 => /usr/lib/libaio.so.1
/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
On 5.7 :
libc.so.1 => /usr/lib/libc.so.1
librt.so.1 => /usr/lib/librt.so.1
libthread.so.1 => /usr/lib/libthread.so.1
libdl.so.1 => /usr/lib/libdl.so.1
libCrun.so.1 => /usr/lib/libCrun.so.1
libaio.so.1 => /usr/lib/libaio.so.1
libw.so.1 => /usr/lib/libw.so.1
/usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1
As you can see, there are slight differences, notable among them being libCrun ad libposix4. Could they be creating any problems ?
I saw a similar issue in this thread : http://forum.sun.com/thread.jspa?threadID=19986&tstart=150
It talks about patches which can solve this issue. Do you have an idea which patch can solve this issue ? (if it can :) )
Your reply is highly appreciated.
Thanks,
Ganesh

Solaris 8 + PHP 4.3.2 + Oracle 9i Instalation Hell

Hi, we've been trying to install PHP with oci8 in Solaris for ours.
The versions of the software we are using are:
Oracle 9.2.0.1.0
PHP 4.3.2
Apache 1.3.28
Solaris 8
We followed the directions from php.net and tried every sugestion in the oci8 manual section.
The farthes we got was full linking of apache and PHP, but when we started Apache with the ORACLE_HOME variable set to the correct directory, we got a core dump without any other message.
This is how we compiled apache + PHP
./configure with-apache=../apache_1.3.28 enable-track-vars
with-oracle=/oracle9i with-dom with-zlib without-mysql
with-oci8 without-pear
make
make install
cd ../apache_1.3.28
LDFLAGS=-R/usr/opt/csw/lib
./configure --activate-module=src/modules/php4/libphp4.a
make
make install
when gdb'ing the httpd process we get
Program received signal SIGSEGV, Segmentation fault.
0xfe9a0660 in slrac () from /oracle9i/lib/libclntsh.so.9.0
Anyone got any pointers?

Hi,
From memory, when we were compiling PHP 4.3.x on Sol 8 SPARC (64 bit) with Apache 1.3.2x and Oracle 9iR2, there was some kind of problem during compilation (using gcc) that stopped it from correctly finding the required Oracle 9i libraries.
Again from memory, we found the workaround by Googling on the Net and then doing a search and replace in the makefile prior to compilation (but after configuration), updating entries from /lib/ to /lib32/ or similar.
Don't remember the exact details, though I hope this is enough of a pointer to be helpful.
Regards and best wishes,
Justin Clift

Indecipherable core dump on Solaris x86_64

On a 64-bit Solaris x86 machine (SunOS tempest-solaris 5.10 Generic_141445-09 i86pc i386 i86pc Solaris), I have been running gcc 4.3.4 (configured for i686-pc-solaris2.10) without a hitch. Both dbx 7.8 and gdb 7.1 are able to read core dumps created from a simple "goodbye, cruel world" program (kind of like "hello world", but it dereferences NULL at the end) built with gcc -m64 -g. However, with a more complex program, neither gdb nor dbx are able to figure it out core dumps (though they can debug it just fine if I set a breakpoint in main and start the program in the debugger).
gdb's failure looks like this:
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-solaris2.10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/net/chronic2nas/emake-slothman-main-201006211520/out/i686_SunOS_64.5.10/ecloud/agent/ecagent...done.
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]
[New LWP 5]
Reading symbols from /usr/lib/amd64/ld.so.1...(no debugging symbols
found)...done.
Loaded symbols for /usr/lib/amd64/ld.so.1
Core was generated by `/opt/ecloud/i686_SunOS.5.10/bin/ecagent
/opt/ecloud/i686_SunOS.5.10/bin/runagen'.
Program terminated with signal 11, Segmentation fault.
#0 0xfffffd7ffeac431c in ?? ()
(gdb) bt
#0 0xfffffd7ffeac431c in ?? ()
Cannot access memory at address 0xfffffd7fffdfed30
(gdb) thread 2
[Switching to thread 2 (LWP 2)]#0 0xfffffd7ffeb2c8fa in ?? ()
(gdb) bt
#0 0xfffffd7ffeb2c8fa in ?? ()
Cannot access memory at address 0xfffffd7ffe1f8dd8
(gdb) thread 3
[Switching to thread 3 (LWP 3)]#0 0xfffffd7ffeb27527 in ?? ()
(gdb) bt
#0 0xfffffd7ffeb27527 in ?? ()
Cannot access memory at address 0xfffffd7ffdfffd68
(gdb) thread 4
[Switching to thread 4 (LWP 4)]#0 0xfffffd7ffeb27527 in ?? ()
(gdb) bt
#0 0xfffffd7ffeb27527 in ?? ()
Cannot access memory at address 0xfffffd7ffde00e78
(gdb) thread 5
[Switching to thread 5 (LWP 5)]#0 0xfffffd7ffeb2c8fa in ?? ()
(gdb) bt
#0 0xfffffd7ffeb2c8fa in ?? ()
Cannot access memory at address 0xfffffd7ffdbffc58
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0xfffffd7fff3c1010 0xfffffd7fff3e614e Yes (*)     /usr/lib/amd64/ld.so.1
(*): Shared library is missing debugging information.and dbx's looks like this:
Reading ecagent
dbx: internal warning: writable memory segment 0x597000[28672] of size 0 in core
dbx: internal warning: writable memory segment 0x59e000[3600384] of size 0 in core
dbx: internal warning: writable memory segment 0xfffffd7ffd405000[4096] of size 0 in core
dbx: internal warning: writable memory segment 0xfffffd7fff3fd000[8192] of size 0 in core
dbx: internal warning: writable memory segment 0xfffffd7fffdfa000[24576] of size 0 in core
core file header read successfully
Reading ld.so.1
dbx: core file read error: address 0xfffffd7fff3fb000 not available
dbx: core file read error: address 0xfffffd7fff3fbae0 not available
dbx: core file read error: address 0x598ff0 not available
dbx: warning: Dbx could not initialize rtld_db
Make sure this is the same version of Solaris where the core dump originated.
Use `help core mismatch' for more info.
(l@1) terminated by signal SEGV (no mapping at the fault address)
0xffffffffffffffff:     <bad address 0xffffffffffffffff>
(dbx) where
[1] 0xfffffd7ffeac431c(0x0, 0x0, 0x784120, 0x170, 0x7, 0xffffffff), at 0xfffffd7ffeac431c
(dbx) threads
dbx: thread related commands not availableI get these errors even when debugging on the exact same machine where the core dump was generated. pstack is similarly confused:
tempest-solaris% pstack /net/chronic2nas/emake-slothman-main-201006211520/logs-201006211902-solx2-ea2/core
core '/net/chronic2nas/emake-slothman-main-201006211520/logs-201006211902-solx2-ea2/core' of 14854:     /opt/ecloud/i686_SunOS.5.10/bin/ecagent /opt/ecloud/i686_SunOS.5.10/bi
----------------- lwp# 1 --------------------------------
fffffd7ffeac431c ???????? ()
----------------- lwp# 2 --------------------------------
fffffd7ffeb2c8fa ???????? ()
----------------- lwp# 3 --------------------------------
fffffd7ffeb27527 ???????? ()
----------------- lwp# 4 --------------------------------
fffffd7ffeb27527 ???????? ()
----------------- lwp# 5 --------------------------------
fffffd7ffeb2c8fa ???????? ()
pstack: warning: librtld_db failed to initialize; symbols from shared libraries will not be availableAre there any arcane configuration parameters in Solaris that affect the generation of core dumps?

Bother. Spoke too soon. One of my tests generated a readable core file, but the rest are having the same issues as detailed above. I am examining the core dump on the machine that generated it. The sizes of the failed tests are 21,522,239 and 21,485,375 and 21,526,447, so I doubt its running into a limit. (The successful one was 27,942,207.)
On this machine, coreadm reports:
     global core file pattern:
     global core file content: all
       init core file pattern: core
       init core file content: all
            global core dumps: disabled
       per-process core dumps: enabled
      global setid core dumps: disabled
per-process setid core dumps: disabled
     global core dump logging: disabledThe machine that got the successful core dump was physical while the ones where it failed were running under VMware LabManager, but I would be very surprised if that makes a difference to this matter. The successful core dump was generated by signal 9 (kill), while the bad ones have all been by signal 11 (segmentation fault).

Core dump in __mutex_alloc_int with 4.7.25 on Solaris 10

I'm a newbie to the forum and to BDB. I'm not a database person either.
I build BDB 4.7.25 and run the test suite (run_all) - it passes a large portion but fails in Env007 after echoing "Env007.h: -create -thread".
I have not yet applied 3 patches for this version but before I go do that please tell me if I'm likely wasting my time or not - I see a number of seemingly disparaging remarks in the source code about Solaris. I see a number of threads close to my issue but nothing on target so far - pardon me if I missed an obvious, on-target thread.
I'm using gcc-3.4.6 from www.sunfreeware.com.
I used this configure command
CC=gcc \
../dist/configure \
--enable-compat185 \
--enable-pthread_api \
--enable-rpc \
--enable-tcl \
--enable-test
Then I start tclsh8.4, source ../test/test.tcl, and execute a test. Here is the stack backtrace from just running Env007:
(gdb) bt
#0 0xfee4e774 in __mutex_alloc_int () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#1 0xfee4f2f4 in __mutex_open () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#2 0xfee9934c in __env_open () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#3 0xfee5fc44 in __env_setup () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#4 0xfee7f1fc in __db_open () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#5 0xfee79f70 in __db_open_pp () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#6 0xfedafb6c in bdb_DbOpen () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#7 0xfedb1950 in berkdb_Cmd () from /spadmin/build/db-4.7.25.NC/build_unix/.libs/libdb_tcl-4.7.so
#8 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#9 0xff2a7c74 in Tcl_EvalEx () from /usr/local/lib/libtcl8.4.so
#10 0xff2a811c in Tcl_EvalObjEx () from /usr/local/lib/libtcl8.4.so
#11 0xff2ac988 in Tcl_EvalObjCmd () from /usr/local/lib/libtcl8.4.so
#12 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#13 0xff2ccc90 in TclExecuteByteCode () from /usr/local/lib/libtcl8.4.so
#14 0xff2cc270 in TclCompEvalObj () from /usr/local/lib/libtcl8.4.so
#15 0xff2fdbd4 in TclObjInterpProc () from /usr/local/lib/libtcl8.4.so
#16 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#17 0xff2a7c74 in Tcl_EvalEx () from /usr/local/lib/libtcl8.4.so
#18 0xff2a811c in Tcl_EvalObjEx () from /usr/local/lib/libtcl8.4.so
#19 0xff2ac988 in Tcl_EvalObjCmd () from /usr/local/lib/libtcl8.4.so
#20 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#21 0xff2ccc90 in TclExecuteByteCode () from /usr/local/lib/libtcl8.4.so
#22 0xff2cc270 in TclCompEvalObj () from /usr/local/lib/libtcl8.4.so
#23 0xff2fdbd4 in TclObjInterpProc () from /usr/local/lib/libtcl8.4.so
#24 0xff2a73b8 in TclEvalObjvInternal () from /usr/local/lib/libtcl8.4.so
#25 0xff2ccc90 in TclExecuteByteCode () from /usr/local/lib/libtcl8.4.so
#26 0xff2cc270 in TclCompEvalObj () from /usr/local/lib/libtcl8.4.so
#27 0xff2a8140 in Tcl_EvalObjEx () from /usr/local/lib/libtcl8.4.so
#28 0xff2d9fcc in Tcl_RecordAndEvalObj () from /usr/local/lib/libtcl8.4.so
#29 0xff2eee04 in Tcl_Main () from /usr/local/lib/libtcl8.4.so
#30 0x000107e0 in main ()
(gdb)
Looking at what the patches do I am inclined to think they are not going to address this. But while awaiting a reply I will start that.
Can anyone say for certain that 4.7.25 can be built and be enterprise class quality with gcc on Solaris 10 [08/07 right now]?
Do I need different configure options?
What else do I need to know?
Many Thanks in Advance

The test has gotten as far as rep036 with zero FAILures but it appears to be deadlocked:
[160]} ptree 26166
3818 /usr/local/sbin/sshd
23791 /usr/local/sbin/sshd -R
23793 /usr/local/sbin/sshd -R
23795 -ksh
26166 tclsh
7627 /usr/local/bin/tclsh8.4
11898 /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script
11900 /usr/local/bin/tclsh8.4
11899 /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script
11901 /usr/local/bin/tclsh8.4
[161]} truss -aefl -rall -vall -wall -p 7627
7627/1: psargs: /usr/local/bin/tclsh8.4
7627/1: lwp_cond_wait(0xFE902AD0, 0xFE902AB8, 0x00000000, 0) (sleeping...)
7627/1: condvar type: USYNC_PROCESS
7627/1: mutex type: USYNC_PROCESS
[162]} truss -aefl -rall -vall -wall -p 11898
11898/1: psargs: /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script.tc
11898/1: waitid(P_PID, 11900, 0xFFBFEA30, WEXITED|WTRAPPED) (sleeping...)
[163]} truss -aefl -rall -vall -wall -p 11900
11900/1: psargs: /usr/local/bin/tclsh8.4
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) (sleeping...)
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
11900/1: pollsys(0xFFBFE480, 0, 0xFFBFE4E8, 0x00000000) = 0
11900/1: timeout: 1.000500000 sec
[164]} truss -aefl -rall -vall -wall -p 11899
11899/1: psargs: /usr/local/bin/tclsh8.4 ../dist/../test/wrap.tcl rep036script.tc
11899/1: waitid(P_PID, 11901, 0xFFBFEA30, WEXITED|WTRAPPED) (sleeping...)
[165]} truss -aefl -rall -vall -wall -p 11901
11901/1: psargs: /usr/local/bin/tclsh8.4
11901/1: lwp_cond_wait(0xFE902C60, 0xFE902C48, 0x00000000, 0) (sleeping...)
11901/1: condvar type: USYNC_PROCESS
11901/1: mutex type: USYNC_PROCESS
^C[166]}
as it has not produced any further output in the last 2 hours. Off to reconfigure as recommended now - I guess my experience suggests this mutex mechanism isn't quite ready for prime time.

Core Dump on Solaris 10 (Signal 10 - Bus Error), but not on Solaris 8?

Hi,
We just moved our product from Solaris 8 to Solaris 10. It runs for months on Solaris 8 without any problems, while core dumped after running about 2 weeks on Solaris 10.
Any clue on what could be wrong is apprecaited.
pam

Hi Andrew,
Appreciate your answer very much. I am very new to Solaris and UNIX in general. Would you please let me know what kind of info would help diagnose the
problem? I have stack pointer, output of "where" from gdb. frme pointer, etc.
pam
===================
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...(no debugging symbols found)
Core was generated by `./warnsrvr'.
Program terminated with signal 10, Bus error.
#0 0x001a3ca8 in __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__ ()
(gdb) where
#0 0x001a3ca8 in __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__ ()
#1 0x001a3ca8 in __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__ ()
Previous frame identical to this frame (corrupt stack?)
======================================
(gdb) disassemble 0x001a3ca8
Dump of assembler code for function __1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__:
0x001a3c24 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+0>: cmp %o0, 1
0x001a3c28 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+4>: be,pn %icc, 0x1a3c38 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+20>
0x001a3c2c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+8>: sethi %hi(0x572000), %l6
0x001a3c30 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+12>: ret
0x001a3c34 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+16>: restore %g0, 0, %o0
0x001a3c38 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+20>: ld [ %l6 + 0x358 ], %l5
0x001a3c3c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+24>: cmp %l5, 0
0x001a3c40 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+28>: bne,pn %icc, 0x1a3c50 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+44>
0x001a3c44 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+32>: cmp %l5, 1
0x001a3c48 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+36>: ret
0x001a3c4c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+40>: restore %g0, 1, %o0
0x001a3c50 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+44>: bne,pn %icc, 0x1a3cb0 <__1cSWPReferenceManagerOInputIonoModel6MrknKIONO_MODEL_khki_nGRESULT__+4>
0x001a3c54 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+48>: sethi %hi(0x1a3c00), %l7
0x001a3c58 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+52>: mov -1, %i1
0x001a3c5c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+56>: sth %i1, [ %fp + -1864 ]
0x001a3c60 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+60>: add %fp, -1824, %o0
0x001a3c64 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+64>: ldd [ %l7 + 8 ], %f0
0x001a3c68 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+68>: call 0x1c87f0 <___const_seg_900001301+16>
0x001a3c6c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+72>: std %f0, [ %fp + -1856 ]
0x001a3c70 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+76>: call 0x1cf888 <__1cKIono2Ascii6FrknKIONO_MODEL_pcki_v_+100>
0x001a3c74 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+80>: add %fp, -1864, %o0
0x001a3c78 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+84>: sllx %i2, 0x30, %o1
0x001a3c7c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+88>: mov %i0, %o0
0x001a3c80 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+92>: srax %o1, 0x30, %o1
0x001a3c84 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+96>: call 0x182cb0 <__1cTGenReferenceManagerOGetCorrections6MrknKCLSGpsTime_rknICLSCoord_rnOCORRECTION_SET__nGRESULT__+3504>
0x001a3c88 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+100>: add %fp, -1864, %o2
0x001a3c8c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+104>: cmp %o0, 1
0x001a3c90 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+108>: be,pn %icc, 0x1a3ca0 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+124>
0x001a3c94 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+112>: mov %i0, %o0
0x001a3c98 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+116>: ret
0x001a3c9c <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+120>: restore %g0, 0, %o0
0x001a3ca0 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+124>: call 0x1a7068 <__1cSWPReferenceManagerPAdjustXTRATimes6MpnZCLSGnssSatellitePredictor_khrnKCLSGpsTime_rd_nGRESULT__+3584>
0x001a3ca4 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+128>: add %fp, -1864, %o1
0x001a3ca8 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+132>: ret
End of assembler dump.
=====================================
(gdb) info registers
g0 0x0 0
g1 0xfd77ecb8 -42472264
g2 0x11 17
g3 0xecf0 60656
g4 0xfd77e304 -42474748
g5 0xfc 252
g6 0x0 0
g7 0xfeda4200 -19250688
o0 0x1 1
o1 0x20 32
o2 0x693500 6894848
o3 0xecf0 60656
o4 0x6a21f0 6955504
o5 0x1 1
sp 0xfd77ec38 0xfd77ec38
o7 0x1a3ca0 1719456
l0 0x1b000021 452984865
l1 0x2ca2a40 46803520
l2 0x40173076 1075261558
l3 0x57d22e16 1473392150
l4 0x3fa80492 1067975826
l5 0x3c06fe49 1007091273
l6 0x4072b4a5 1081259173
l7 0x410d711d 1091399965
i0 0x421c0000 1109131264
i1 0xffffffff -1
i2 0x1d000018 486539288
i3 0x2ca2808 46802952
i4 0x40138e4a 1075023434
i5 0x8b122e16 -1961742826
fp 0xbfb17c3b 0xbfb17c3b
i7 0xa817f0db -1474826021
y 0x3 3
psr 0xfe401007 -29356025
wim 0x0 0
tbr 0x0 0
pc 0x1a3ca8 0x1a3ca8 <__1cSWPReferenceManagerMInputUtcInfo6MrknIUTC_INFO_khki_nGRESULT__+132>
npc 0x1a3cac 0x1a3cac <__1cSWPReferenceManagerOInputIonoModel6MrknKIONO_MODEL_khki_nGRESULT__>
fsr 0x400420 4195360
csr 0x0 0

Segmentation Fault on Solaris JVM

Hi,
We have a Java application that executes all 'C' code through JNI code.
It works fine on NT but on solaris, the JVM suddenly crashes with a
segmentation fault. The crashes are random. We did a lot of debugging to ensure that the JVM doesn't crash when we are in the 'C' code.
We are using jdk1.4.0-b92. Any ideas?
Here's the stack trace from gdb:
Program received signal SIGSEGV, Segmentation fault.
0xfa535000 in ?? ()
(gdb) bt
#0 0xfa535000 in ?? ()
#1 0xfa53908c in ?? ()
#2 0xfa538f50 in ?? ()
#3 0xfa534480 in ?? ()
#4 0xfa52d560 in ?? ()
#5 0xfa405c54 in ?? ()
#6 0xfa405b88 in ?? ()
#7 0xfa405da8 in ?? ()
#8 0xfa405da8 in ?? ()
#9 0xfa405da8 in ?? ()
#10 0xfa400440 in ?? ()
#11 0xfe0fd9ac in __1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_ ()
#12 0xfe10f644 in __1cJJavaCallsMcall_virtual6FpnJJavaValue_nLKlassHandle_nMsymbolHandle_4pnRJavaCallArguments_pnGThread__v_ ()
#13 0xfe10f4a4 in __1cJJavaCallsMcall_virtual6FpnJJavaValue_nGHandle_nLKlassHandle_nMsymbolHandle_5pnGThread__v_ ()
#14 0xfe10f42c in __1cMthread_entry6FpnKJavaThread_pnGThread__v_ ()
#15 0xfe10f13c in __1cKJavaThreadDrun6M_v_ ()
#16 0xfe0fc284 in _start ()

I had same segmentation fault and found out some char array variable's value length is over the size of char array variable. After fixed it, then it doesn't have that segmentation fault.
In Solaris, when I use java JFileChooser to select a file, the file path usually including a lot of "../" which causes a path over 200 char long. When I assigned that path to a char array variable which only have 200 char length, the segmentation fault happened.

Lpstat -t -o commands hangs with no output on SOlaris 10

Hi All,
We have ( SunOS 5.10 Generic_127111-06 sun4u sparc SUNW,SPARC-Enterprise),on a box .
The issue is when ever lpstat command is used to see weather there are any queues in the printer it hangs...
But print queue is getting cleared want to know weather its a Bug in Solaris 10...........
We have configured the printer on port 9100...
cosuaor19:> cat /etc/lp/printers/ALBH_SHIP_LN1/configuration
Banner: off
Content types: simple,postscript
Device: /dev/null
Interface: /usr/lib/lp/model/netstandard
Printer type: hplaser
Modules:
Options: dest=192.100.9.106:9100,protocol=tcp
cosuaor19:> telnet 192.100.9.106 9100
Trying 192.100.9.106...
Connected to 192.100.9.106.
Escape character is '^]'.
^]
telnet> quit
Connection to 192.100.9.106 closed.
cosuaor19:>
So any help on this would be appreciated ...

gdb shows that asynchronous i/o for sockets is handled only in user space via creating threads.
Additional info can be found on http://mail.opensolaris.org/pipermail/perf-discuss/2007-February/001621.html too.

Solaris-express-10/03 emacs core dump

I've just installed emacs on Solaris express 10/03 in Sun-Blade-100 box and having problem in gui mode. Emacs only runs with -nw in text mode but not in gui mode. Starting with no options, it has segmentation fault with coredump. Although it is not running on this machine, I can still have sshed emacs running in gui mode from other computers on that machine. By examining the core file with gdb, it is highly likely that realfree () from /lib/libc.so.1 from emacs causing the problem. It there any way to fix this problem? -Thanks
P/S emacs coredump and corresponding assembler code.
#0 0xfeeca788 in realfree () from /lib/libc.so.1
0xfeeca788 <realfree+100>: ld [ %o7 + 8 ], %l1

The usenet thread starting with this article...
http://groups.google.de/groups?selm=lmsmmwz81k.fsf%40privacy.net
recommends to work around this problem by running emacs with 'setenv LD_NODIRECT 1'.

Gdb 6.2.1 in Solaris 10

Similar Messages

Maybe you are looking for