Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> Development Tools >> Solaris and Linux Development Tools

Getting problem in Xerces_2_7 library on Solaris5.8(Sparc) and C++(5.5)

Hi

I have build xerces_2_7 source (64-bit mode)on Solaris sparc(5.8) using SunStudio 8

compiler version (CC: Sun C++ 5.5 Patch 113817-14 2005/07/19).

I am getting problem in xerces library here is the stack trace

signal BUS (invalid address alignment) in realfree at 0xffffffff77d4a2ec

0xffffffff77d4a2ec: realfree+0x0078:ldx[%i0 + 16], %o1

Current function is xercesc_2_7::MemoryManagerImpl::deallocate

47::operator delete(p);

[1] realfree(0x107eb2524, 0xffffffff77ec1780, 0x107eb1990, 0xffffffff77eb4f60, 0x107eb1980, 0xba7)

[2] _free_unlocked(0xffffffff77ec1668, 0xffffffff77eb4f60, 0x1080098b0, 0xffffffff785069c4, 0x1080

[3] free(0x1080098b0, 0x0, 0x106c5c460, 0xffffffff785069c4, 0xffffffff7ef013c0, 0x0), at 0xfffffff

[4] operator delete(0x1080098b0, 0x106c5c4b0, 0xe, 0xffffffff785069c4, 0xffffffff7f72c930, 0x0), a

=>[5] xercesc_2_7::MemoryManagerImpl::deallocate(this = 0x106c06b30, p = 0x1080098b0), line 47 in "M

[6] xercesc_2_7::XMLBuffer::~XMLBuffer(this = 0x108009838), line 76 in "XMLBuffer.hpp"

[7] xercesc_2_7::SchemaValidator::~SchemaValidator(this = 0x1080097d8), line 340 in "SchemaValidat

[8] __SLIP.DELETER__L(0x1080097d8, 0x1, 0xffffffff7dc000e8, 0xffffffff785069c4, 0x765f0024, 0x0),

[9] xercesc_2_7::IGXMLScanner::cleanUp(this = 0x1080043a8), line 559 in "IGXMLScanner.cpp"

[10] xercesc_2_7::IGXMLScanner::~IGXMLScanner(this = 0x1080043a8), line 158 in "IGXMLScanner.cpp"

[11] __SLIP.DELETER__P(0x1080043a8, 0x1, 0xffffffff7f72c930, 0xffffffff7ef013c0, 0xffffffff7ef013c

[12] xercesc_2_7::AbstractDOMParser::cleanUp(this = 0xffffffff7ffedfb0), line 160 in "AbstractDOMP

[13] xercesc_2_7::AbstractDOMParser::~AbstractDOMParser(this = 0xffffffff7ffedfb0), line 128 in "A

[14] xercesc_2_7::XercesDOMParser::~XercesDOMParser(this = 0xffffffff7ffedfb0), line 65 in "Xerces

[15] xercesc_2_7::XSDDOMParser::~XSDDOMParser(this = 0xffffffff7ffedfb0), line 64 in "XSDDOMParser

[16] xercesc_2_7::IGXMLScanner::resolveSchemaGrammar(this = 0x107fcefb8, loc = 0x107fd5fa0, uri =

[17] xercesc_2_7::IGXMLScanner::scanRawAttrListforNameSpaces(this = 0x107fcefb8, attCount = 2), li

[18] xercesc_2_7::IGXMLScanner::scanStartTagNS(this = 0x107fcefb8, gotData = true), line 2211 in "

[19] xercesc_2_7::IGXMLScanner::scanContent(this = 0x107fcefb8), line 889 in "IGXMLScanner.cpp"

[20] xercesc_2_7::IGXMLScanner::scanDocument(this = 0x107fcefb8, src = CLASS), line 213 in "IGXMLS

[21] xercesc_2_7::SAXParser::parse(this = 0x107fcdd08, source = CLASS), line 544 in "SAXParser.cpp

In the xerces build instruction they explicit told that use Sun Workshop 6 update 2 compiler.

Also attached the link of build instruction

http://xml.apache.org/xerces-c/build-winunix.html#UNIX

What could be the reason for getting core dump on Sola(5.8 ) using SunStudio8

What is the difference between Sun Workshop 6 update 2 and SunStudio 8.

Is there any specific patch for SunStudio 8 for xerces_2_7

Thanks in advance

-Riaj

[3162 byte] By [koresha@123] at [2007-11-26 10:48:17]
«« user add fails in Java messaging server using da
»» Oracle Type4 driver (ojdbc14.jar) connection proble
# 1
For the quick workaround consider using a non-default -xmemalign= value.The "-xmemalign=1i" flag should fix all the problems with alignment but the result can appear awfully slow.Check out: http://docs.sun.com/source/817-5064/cc_ops.app.html#32726
horsh at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 2

Hi ,

I recompiled with "-xmemalign=1i" option . Now I am getting this error i.e

1 (l@1) signal SEGV (no mapping at the fault address) in __do_misaligned_ldst_instr at 0x1005e4748

0x00000001005e4748: __do_misaligned_ldst_instr+0x01c8: ldx[%l4], %g1

Current function is xercesc_2_7::MemoryManagerImpl::deallocate

47::operator delete(p);

Thanks

-Riaj

koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 3

Hi ,

can I apply http://xml.apache.org/xerces-c/faq-build.html#faq-11

following patch on Solaris2.8

this is from xerces site>>>>>>>

Why does my multi-threaded application crash on Solaris 2.6?

The problem appears because the throw call on Solaris 2.6 is not multi-thread safe. Sun Microsystems provides a patch to solve this problem. To get the latest patch for solving this problem, go to SunSolve.sun.com and get the appropriate patch for your operating system. For Intel machines running Solaris, you need to get Patch ID 104678. For SPARC machines you need to get [b]Patch ID #105591[/b]

koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 4

A crash in the system malloc or free is due to heap corruption, or to use of an invalid pointer. See reply #2 in this thread for more details:

http://forum.sun.com/thread.jspa?threadID=27281

If the program includes code that you wrote youself, look for the kinds of programming errors described in the reference.

If the program consists only of Xerces code, the problem is unlikely to be due to a programming error error in Xerces, but could be due to a configuration error. Some things to check:

1. Be sure that Xerces is intended to be compiled as a 64-bit program. A program intended for use only as a 32-bit program is unlikely to work when compiled as a 64-bit program. If that's the problem, remove the -xarch=v9 option and rebuild everything.

2. Most Open Source code does not consider Sun C++ in its auto configuration step. You will commonly see conditional code that adjusts configuration parameters for specific compilers, but not for Sun C++. Declarations can wind up missing, and configuration parameters can be set wrong. You should review the configuration step, and be sure that Sun C++ doesn't fall outside the process.

3. The default thread library on Solaris 8 has some problems. You should use the alternative thread library instead, as explained in the C++ Users Guide and the Solaris Multhreaded Programming Guide.

To use the library, add -L/usr/lib/lwp (for 32-bit programs) or -L/usr/lib/lwp/64 (for 64-bit programs) to every CC command line.

The alternative library is the default thread library on Solaris 9 and 10, so you don't need to do anything special to get it.

4. You might be running into a compiler bug that was later fixed. Try using Sun Studio 11, which is free for all uses. You can get it here:

http://developers.sun.com/sunstudio

Apply all current patches, which you can get here:

http://developers.sun.com/sunstudio/downloads/patches/index.jsp

clamage45 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 5
Hi ,ThanksThe same xerces2.7 is working fine Hp64(itanium)/AIX5L(xlC6) without modifying single line in xerces2.7 code.I think it might be the compiler problem. So I will try with Sunstudio11.Is it fine.Thanks-Riaj
koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 6
OK, but see item #2 and #3 in my previous post.
clamage45 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 7
Thanks Claimage,Also I check patch for shared library 64 bit for C++Current patch is availabel in my system is 108435-12.Also I requested to instaled latest patch 108435-22.This might be the problem.-Riaj
koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 8

Hi Clamage,

I got similar bug in the following url

http://onesearch.sun.com/search/onesearch/index.jsp?qt=SRDB+72547+&site=sun solve&otf=ss&col=support-sunsolve&otf=sunsolve&site=ss&col=s earch-sunsolve

I think these bugs already been fixed.

How can I see the details information regarding these two bugs.

Thanks in advance

-Riaj

koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 9

This reference in the URL that you point to explains some of the issues.

http://sunsolve.sun.com/search/document.do?assetkey=1-25-72547-1

Bug details are not generally available for public query, except for bugs submitted via bugs.sun.com.

Please pursue the suggestions already presented.

clamage45 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 10

Hi Clamage,

I found the similar kind of problem which hangs in multithreaded application.

http://sunsolve.sun.com/search/document.do?assetkey=1-26-46867-1

Also in my case library which is built is pointing to the same path as described in document

here is the details

ldd libxerces-c.so.27

libpthread.so.1 =>/usr/lib/sparcv9/libpthread.so.1

libnsl.so.1 =>/usr/lib/sparcv9/libnsl.so.1

libsocket.so.1 =>/usr/lib/sparcv9/libsocket.so.1

libdl.so.1 =>/usr/lib/64/libdl.so.1

libc.so.1 =>/usr/lib/64/libc.so.1

libmp.so.2 =>/usr/lib/64/libmp.so.2

libthread.so.1 =>/usr/lib/lwp/sparcv9/libthread.so.1

/usr/platform/SUNW,Sun-Fire-V440/lib/sparcv9/libc_psr.so.1

here it should be pointing to correct library.please let me know is it the correct order of compilation

Thanks

-Riaj

koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 11
Try this before running your app:export LD_LIBRARY_PATH_64=/usr/lib/lwp/sparcv9:$LD_LIBRARY_PATH_64This should enable your app to use thread libraries from /usr/lib/lwp instead of /usr/lib.
MaximKartashev at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 12

But my other libraries which are built for my application are in LD_LIBRARY_PATH i.e

/usr/lib/lwp/64:/usr/lib/lwp/sparcv9:/home6/smoh/p4code/build_sun_main/mydir/xe rces-c/lib:

is it wrong?

Also my details compile options are

1)CC -w -[b]mt[/b] -KPIC-DSOLARIS [b]-D_REENTRANT[/b] -DXML_USE_NATIVE_TRANSCODER

-DXML_USE_INMEM_MESSAGELOADER -DXML_USE_PTHREAD -DXML_USE_NETACCESSOR_SOCKET -DXML_BITSTOBUILD_64

2)LIBRARIES="-lpthread -lnsl -lsocket"

3)make all -r -f makefile COMPILER="$COMPILER" GLOBAL_CFLAGS="$TEST_FLAGS_O1" GLOBAL_INCLUDEDIRS="$INCLUDEDIRS" G

LOBAL_LIBRARIES="$LIBRARIES"

Is there any problem if iam using both -mt -D_REENTRANT

and my application hangs on sUN od2.8

-Riaj

koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 13

also here is pstack core

$ pstack core

core 'core' of 26653:al_engine -PLocaleUTF8 -T14 -l"/home6/smohe/DI2710/log/tracelog.txt

-- lwp# 1 / thread# 1 --

ffffffff781181d8 __lwp_park (ffffffff7821b878, ffffffff780be308, ffffffff780be308, 0, ffffffff74000000,

ffffffff74000000) + 14

ffffffff781147d0 slow_lock (ffffffff780be308, ffffffff74000000, ffffffff780be308, ffffffff780be0b0, ffff

ffff780be0b8, 0) + 54

ffffffff77f49bf4 malloc (20, ffffffff780be0b0, ffffffff7821a000, ffffffff780be0e0, 0, 0) + 18

ffffffff77f9adac _findiop (ffffffff780c2c90, ffffffff780be098, 0, ffffffff780b4f60, 0, 0) + 34

ffffffff77f9a818 fdopen (11, 105093b62, 11, ffffffff7ffed518, 0, 0) + 4

ffffffff77f9d020 popen (10, 11, 6824, 1055b6030, 681d, 1055b6030) + 220

0000000102fddca8 __1cLActaHandler6Fi_v_ (a, 1055b6030, ffffffff7ffeea00, 0, 0, 0) + 1d8

ffffffff78118394 __sighndlr (a, 0, ffffffff7ffeea00, 102fddad0, 0, 0) + c

ffffffff78111edc call_user_handler (a, ffffffff74000000, 1, ffffffff7821ca60, ffffffff7821c920, 140) + 2

68

ffffffff781120c8 sigacthandler (ffffffff74000000, ffffffff7ffeea00, ffffffff7821a000, 0, 0, a) + 6c

called from signal handler with signal 1946157056 (SIG Unknown)

ffffffff77f4a2ec realfree (106cfb3e4, ffffffff780c1780, 106cfa850, ffffffff780b4f60, 106cfa840, ba7) + 7

8

ffffffff77f4ab88 _free_unlocked (ffffffff780c1668, ffffffff780b4f60, 106f97870, ffffffff780b4f60, 106fa9

cf0, 41) + ac

ffffffff77f4aacc free (106f97870, ffffffff780be308, 106f06ae0, 0, 0, 0) + 20

ffffffff7870787c __1c2k6Fpv_v_ (106f97870, 106f06b30, e, ffffffff780b4f60, 1, 11) + 4

ffffffff7e01fd18 __1cLxercesc_2_7RMemoryManagerImplKdeallocate6Mpv_v_ (105674dc0, 106f97870, 106f97700,

ffffffff780b4f60, 1, 31) + 10

ffffffff7e364214 __1cLxercesc_2_7JXMLBuffer2T5B6M_v_ (106f977f8, 106f06ae0, 1, ffffffff780b4f60, 106fc99

60, 21) + 24

ffffffff7e358008 __1cLxercesc_2_7PSchemaValidator2T6M_v_ (106f97798, ff000000, 106f57c60, 106f9f3d8, 106

f5f048, 106f5faa8) + 100

ffffffff7e365298 __SLIP.DELETER__L (106f97798, 1, 106f5f7e0, 106f5e740, f, 105674dc0) + 10

ffffffff7dff4e70 __1cLxercesc_2_7MIGXMLScannerHcleanUp6M_v_ (106f92368, 106f99250, 3, 0, 0, 31) + 108

ffffffff7dff36b0 __1cLxercesc_2_7MIGXMLScanner2T6M_v_ (106f92368, 106f57c60, 0, 0, 0, 0) + 10

ffffffff7e004678 __SLIP.DELETER__P (106f92368, 1, 0, 0, 0, 0) + 10

ffffffff7e14cbd0 __1cLxercesc_2_7RAbstractDOMParserHcleanUp6M_v_ (ffffffff7ffeff10, 106fa2590, 1, 0, 1,

106fdf508) + 110

ffffffff7e14c654 __1cLxercesc_2_7RAbstractDOMParser2T5B6M_v_ (ffffffff7ffeff10, 106f99460, 2, 106faaa08,

1, 0) + dc

ffffffff7e1673d8 __1cLxercesc_2_7PXercesDOMParser2T5B6M_v_ (ffffffff7ffeff10, 106f57ce8, 106faaad0, 106f

a6450, 106fc9960, 105674dc0) + d8

ffffffff7e3c2128 __1cLxercesc_2_7MXSDDOMParser2T6M_v_ (ffffffff7ffeff10, 106f9f3d8, 106f56fa8, 106f9f3d8

, 106f5f048, 106f5faa8) + 88

ffffffff7e00f384 __1cLxercesc_2_7MIGXMLScannerUresolveSchemaGrammar6MkpkHkp2_v_ (106f5faa8, 106f9ade0, 1

06f5e748, 106f5e740, f, 105674dc0) + d7c

ffffffff7e00e1b0 __1cLxercesc_2_7MIGXMLScannerbCscanRawAttrListforNameSpaces6Mi_v_ (106f5faa8, 2, 106f57

0a8, ffffffff7fff0582, 0, 0) + 3e0

ffffffff7dff9920 __1cLxercesc_2_7MIGXMLScannerOscanStartTagNS6Mrb_b_ (106f5faa8, ffffffff7fff069f, 0, 0,

0, 0) + 410

ffffffff7dff5c18 __1cLxercesc_2_7MIGXMLScannerLscanContent6M_b_ (106f5faa8, ffffffff7fff0aa8, ffffffff7e

022d38, 0, 0, 0) + 268

ffffffff7dff3940 __1cLxercesc_2_7MIGXMLScannerMscanDocument6Mrkn0ALInputSource__v_ (106f5faa8, ffffffff7

fff0aa8, ffffffff7e172718, 0, 0, 0) + 150

ffffffff7e16fdc0 __1cLxercesc_2_7JSAXParserFparse6Mrkn0ALInputSource__v_ (106f5e728, ffffffff7fff0aa8, f

fffffff7fff0aa0, 10513beda, 7, ffffffff7fff0aa4) + 130

0000000103f77db0 __1cVActaXMLSchemaMetaDataFparse6M_v_ (106f5e3f0, 0, 0, 0, 0, 0) + 430

0000000103f83108 __1cVActaXMLSchemaMetaDataSgenerate_node_tree6M_pnIActaNode__ (106f5e3f0, 106cd9320, 1,

104274, ffffffff7880ca70, 0) + 18

000000010263af98 __1cPNRDM2XML_Schema2t6MrnJElem_vect_IpnKOptionList_rknJDIUString_III5I5_v_ (106f5d9a0,

106d97710, 0, 106cd9320, ffffffff7fff0f70, 0) + 428

00000001034686c0 __1cHLoadXMLEopen6MrnKXTran_desc__v_ (0, 0, 1, ffffffff7fff0f38, 0, ffffffff7fff0f30) +

220

0000000101211f44 __1cKXTran_descEopen6M_v_ (106ee17a0, ffffffff7fff13b0, 0, 104274, ffffffff7880ca70, 0)

+ 6c

00000001011494e0 __1cLXProc_childEopen6M_v_ (106ee2a30, ffffffff7fff13b0, 106f5b7b8, 10119ef68, 1011a17a

0, 106f5aff8) + 30

000000010114768c __1cOXProc_childrenEopen6M_v_ (106eb9c78, 0, 0, 0, 0, 0) + 4a4

000000010119222c __1cOXDataflow_descNexecuteInline6M_v_ (106eb9b70, 10553a250, ffffffffffffffff, 0, ffff

ffff7880ca70, 1) + 4c

000000010104f034 __1cOXDataflow_infoHexecute6MrnOXDataflow_desc__v_ (3b, 0, ffffffff7fff2050, 104274, ff

ffffff7880ca70, ffffffff7fff2330) + 894

00000001011912ac __1cOXDataflow_descHexecute6M_v_ (106eb9b70, 0, 106d95300, 0, ffffffff7fff232c, fffffff

f7fff2330) + 11c

0000000101050110 __1cOXDataflow_infoHcompute6MpnKXCall_desc_nKXExec_flag_rirnJDIUString_6_v_ (ffffffff7f

ff2330, ffffffff7fff2338, 0, ffffffff7fff232c, ffffffff7fff2330, ffffffff7fff2338) + 110

0000000101050ae4 __1cOXDataflow_infoHcompute6MpnKXCall_desc_nKXExec_flag__v_ (106d95300, 0, 0, 104274, f

fffffff7880ca70, 3) + 14c

0000000103ef4890 __1cXAE_Main_Process_Options6FippHLrI_i_ (ffffffff7fffc238, ffffffff7fffc230, 1, 0, 0,

ffffffff7fffdf88) + dd08

0000000103ee6960 AE_Main (17, ffffffff7fffe1a8, 1, 34, 1044a4, c) + 9e8

0000000103edad88 main (17, ffffffff7fffe1a8, ffffffff7fffe268, 0, 0, 100000000) + 190

00000001005e4a5c _start (0, 0, 0, 0, 0, 0) + 17c

-- lwp# 2 / thread# 2 --

ffffffff781181d8 __lwp_park (ffffffff7821b878, ffffffff780be0f0, ffffffff780be0f0, 0, ffffffff74000400,

ffffffff74000400) + 14

ffffffff781147d0 slow_lock (ffffffff780be0f0, ffffffff74000400, ffffffff780be0f0, 1400, f, 106d8e4e0) +

54

ffffffff77f9d24c _delete (ffffffff780b4f60, f, ffffffffffffffff, 681e, 0, a) + 18

ffffffff77f9d0cc pclose (ffffffff780bd770, ffffffff780bd770, 1, ffffffff780b4f60, 401, ffffffff720fb4d8)

+ c

00000001042e21dc __1cQSUNMemoryMonitorMgetSysConfig6Fn0AOSYS_PARAM_TYPE__i_ (3, ffffffff78970bc0, 0, 104

274, ffffffff7880ca70, 0) + 1fc

00000001042e1e38 __1cQSUNMemoryMonitorRcheckSystemStatus6M_nNmemoryMonitorMMEMORY_STATE__ (106e18fc0, 0,

106d7d730, ffffffff720fb978, 0, 0) + 80

0000000102f44614 __1cNmemoryMonitorEmain6M_v_ (106e18fc0, 106d7d898, ffffffff720fba00, ffffffff73310030,

ffffffff7821a000, ffffffff74000400) + 15c

0000000102f5a0f0 __1cPRWTFunctor0MImp4nNmemoryMonitor_Cv_Drun6kM_v_ (106eb0230, 106d7d898, ffffffff7821a

000, 0, 0, 0) + 20

ffffffff799bcf28 __1cKRWFunctor02f6kM_v_ (ffffffff720fbbc8, 106d7d898, 0, 0, 0, 0) + 28

ffffffff799bc71c __1cTRWThreadFunctionImpDrun6M_v_ (106d7d720, 0, 0, 0, 0, 0) + 9c

ffffffff7995d440 __1cNRWRunnableImpEexec6M_v_ (106d7d720, 106d7d720, 0, 0, 0, 0) + 160

ffffffff799bfcb8 __1cLRWThreadImpEexec6M_v_ (106d7d720, 0, 0, 0, 0, 0) + 68

ffffffff799bfbe4 RWThreadImp_entry (106d7d720, ffffffff74000400, 0, 0, 0, 0) + c

ffffffff781180c4 _lwp_start (0, 0, 0, 0, 0, 0)

-- lwp# 3 / thread# 3 --

ffffffff77fa4b98 _libc_sigtimedwait (ffffffff74000800, f, 0, 0, 0, 0) + 8

ffffffff77f9fd2c __posix_sigwait (ffffffff71efbf30, ffffffff71efbf28, 0, 0, 0, 0) + 18

0000000101268430 __1cLsigterm_thr6Fpv_0_ (0, ffffffff74000800, 0, 0, 0, 0) + 50

ffffffff781180c4 _lwp_start (0, 0, 0, 0, 0, 0)

-- lwp# 4 / thread# 4 --

ffffffff781181d8 __lwp_park (106dd75a8, ffffffff74000c00, ffffffff7821a000, 0, ffffffff74000c8e, 3e0) +

14

ffffffff78115b6c _cond_wait (106dd75a8, 106dd7578, ffffffff71cfb5f0, 1f, 0, 0) + 60

ffffffff78115b98 cond_wait (106dd75a8, 106dd7578, 106dd7578, 1, 0, 1) + 10

ffffffff78115bd4 pthread_cond_wait (106dd75a8, 106dd7578, d, 104274, ffffffff7880ca70, 0) + 8

ffffffff7c30a25c __1cLRWConditionEwait6M_v_ (106dd75a0, 0, ffffffff71cfb948, 1050316cc, d, ffffffff71cfb

94c) + ec

00000001026b99d0 __1cMvcharManagerEmain6M_v_ (106dd7530, 106eb9a18, ffffffff71cfba00, ffffffff73310060,

ffffffff7821a000, ffffffff74000c00) + 1f8

00000001026c85d8 __1cPRWTFunctor0MImp4nMvcharManager_Cv_Drun6kM_v_ (106d7d8b0, 106eb9a18, ffffffff7821a0

00, 0, 0, 0) + 20

ffffffff799bcf28 __1cKRWFunctor02f6kM_v_ (ffffffff71cfbbc8, 106eb9a18, 0, 0, 0, 0) + 28

ffffffff799bc71c __1cTRWThreadFunctionImpDrun6M_v_ (106eb98a0, 0, 0, 0, 0, 0) + 9c

ffffffff7995d440 __1cNRWRunnableImpEexec6M_v_ (106eb98a0, 106eb98a0, 0, 0, 0, 0) + 160

ffffffff799bfcb8 __1cLRWThreadImpEexec6M_v_ (106eb98a0, 0, 0, 0, 0, 0) + 68

ffffffff799bfbe4 RWThreadImp_entry (106eb98a0, ffffffff74000c00, 0, 0, 0, 0) + c

ffffffff781180c4 _lwp_start (0, 0, 0, 0, 0, 0)

RM

koresha@123 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 14

> Hi Clamage,

>

> I found the similar kind of problem which hangs in

> multithreaded application.

> http://sunsolve.sun.com/search/document.do?assetkey=1-

> 26-46867-1

> Also in my case library which is built is pointing to

> the same path as described in document

> here is the details

> ldd libxerces-c.so.27

> libpthread.so.1 => /usr/lib/sparcv9/libpthread.so.1

> libnsl.so.1 =>/usr/lib/sparcv9/libnsl.so.1

> libsocket.so.1 =>/usr/lib/sparcv9/libsocket.so.1

> libdl.so.1 => /usr/lib/64/libdl.so.1

> libc.so.1 =>/usr/lib/64/libc.so.1

> libmp.so.2 => /usr/lib/64/libmp.so.2

> libthread.so.1 =>/usr/lib/lwp/sparcv9/libthread.so.1

> /usr/platform/SUNW,Sun-Fire-V440/lib/sparcv9/libc_psr.so.1

These all look correct.

clamage45 at 2007-7-7 3:00:41 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 15

> Try this before running your app:

> export LD_LIBRARY_PATH_64=/usr/lib/lwp/sparcv9:$LD_LIBRARY_PATH_64

No, you don't need to do that. Preferably, do not use LD_LIBRARY_PATH or its variants at all for any purpose. See this reference for an explanation.

http://blogs.sun.com/rie/entry/tt_ld_library_path_tt

See my eariler discussion for using the lwp version of the threads library.

clamage45a at 2007-7-21 15:28:46 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 16

Hi Clamage,

Xerces 2.7 certified on Forte 6 update2. In order to resolved the memory alignment problem can I build the whole product with Forte6 update2.

Or

Can I installed latest patchfor sunstudio8 i.e common patch (112763-19) and for shared libray 64 bit (108435-22)

Also my existing m/c contiaining 108435-12 patch.

Please give some suggestion.

Thanks in advance

-riaj

koresha@123a at 2007-7-21 15:28:46 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 17

> Xerces 2.7 certified on Forte 6 update2. In order to

> resolved the memory alignment problem can I build the

> whole product with Forte6 update2.

If it works using FD6u2 and you have a copy, you can use it. FD6u2 is End Of Life, however, so I would not depend on using it for production code. Little support is available, and you generally cannot get any more licenses for it. (Sometimes exception are made.)

But if the code works with FD6u2 and not with Studio 11, I would suspect one of the items I mentioned in my first reply: The source code might be conditionalized on that specific compiler. If that is the case, change the condition to accept any value of __SUNPRO_CC >= 0x530.

> Can I installed latest patchfor sunstudio8 i.e common

> patch (112763-19) and for shared libray 64 bit

> (108435-22)

Why do you want to use the obsolete Sun Studio 8 instead of the current Sun Studio 11? As I suggested originally, get Sun Studio 11, which is free, and get all the current patches.

>

> Also my existing m/c contiaining 108435-12 patch.

That is not a very recent patch. The current version is 108435-22.

clamage45a at 2007-7-21 15:28:46 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 18

Hi Clamage,

I have the following queries

1)Are you support Sun One Studio8 (C++ 5.5) now.

2) What is the latest patch available for C++(5.5)compiler. I have CC: Sun C++ 5.5 Patch 113817-14 2005/07/19

3)Do you know about the internal/memory alignment bug which is being fixed in sunstudio10/11. Do you provide some different patch for Sunstudio 8.

Thanks in Advance.

-Riaj

koresha@123a at 2007-7-21 15:28:46 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 19

> Hi Clamage,

>

> I have the following queries

>

> 1)Are you support Sun One Studio8 (C++ 5.5) now.

You can find current status of all Sun Studio versions here:

http://developers.sun.com/sunstudio/support/support_matrix.jsp

>

> 2) What is the latest patch available for

> C++(5.5)compiler. I have CC: Sun C++ 5.5 Patch

> 113817-14 2005/07/19

You can find all current patches here:

http://developers.sun.com/sunstudio/downloads/patches/index.jsp

>

> 3)Do you know about the internal/memory alignment bug

> which is being fixed in sunstudio10/11. Do you

> provide some different patch for Sunstudio 8.

Sorry, I need more of a clue. Do you know the bug number?

clamage45a at 2007-7-21 15:28:46 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 20
ClueThe same code working fine in aCC(HP-UX itanium) and xlc 6 of (AIX)Getting meomory alignment problem in Xerces 2.7 -Riaj
koresha@123a at 2007-7-21 15:28:46 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
# 21
Now we are back to where we started.Getting an error on a different platform with a different compiler does not mean that platform or the compiler is at fault. Please review all the comments I have already posted.
clamage45a at 2007-7-21 15:28:46 > top of Java-index,Development Tools,Solaris and Linux Development Tools...
Development Tools
Solaris and Linux Development Tools

Development Tools New Topic

Development Tools Hot Topic

Development Tools

All Classified