Stack Overflow Exception

Hi all,
I am trying to serialize a directed graph. I have Node objects, and each Node object has a Vector of Node objects as one of its fields. The directed graph is stored as a Vector of Node Objects. The Node object and the DirectedGraph objects are structured as follows:
public class Node
private int nodeID;
private Vector adjacentNodes;
// Constructor..
// Some more methods
public class DirectedGraph
private Vector nodes;
// Other fields and methods.
When the no of nodes is very large (~ 10000), I get a StackOverflow error, which I think is because of the recursive serialization. I do not get the exception for a small set of nodes (~1000).
I did read someplace that if the stack depth is greater than 2000, the VM throws the exception.
Are there any workarounds for this (without any changes to the data representation) ?
Are there other custom serializers which detect infinite cycles ?
Or, (worst case), do I have to write my own serializer?
Suggestions, links, will surely help.
Thank you,
Astranomina

As mentioned above, Java serialization handles a cyclic object graph by writing a representation of the object reference to the stream for subsequent occurrances, so this does not cause infinite recursion.
However, if your structure has 25,000 levels then I'm not surprised that you got StackOverflow and for something this size I don't think that trying to increase the stack size is the way to go.
As intimated by Ernimril, a better approach would be to devise a serialized form that is more sympathetic to the environment. I would recommend that you program to interface and use object replacements. That way, the issues regarding serialization can be hidden and coded in the appropriate place:
public interface DirectedGraph
public interface Node
public class LocalDirectedGraph implements DirectedGraph
// your current code (and the same for LocalNode)
Object writeReplace() throws ObjectStreamException
  // flatten structure
  return SerializedDirectedGraph
public class SerializedDirectedGraph implements DirectedGraph
  // a flat structure that can be used to rebuild the hierarchical one
Object readResolve() throws ObjectStreamException;
  // rebuild hierarchy
  return LocalDirectedGraph
}Perhaps traverse the original graph and write a linear structure of the individual objects and some info about what level they are at. Implement writeReplace and place this code in it, returning a SerializedDirectedGraph. At the receiving end implement readResolve and reconstruct the original, returning a LocalDirectedGraph. Everywhere else in your code refer to your objects by the interfaces. Because the JDK handles the cyclic references thing you still get the original object graph, you are just intervening to make the structure more serialization-friendly.
Check out [url http://java.sun.com/j2se/1.4.2/docs/guide/serialization/spec/output.html#wp5324]this section of the serialization spec. I've used this feature for different reasons, as well as other hooks available in Serialization, and am very impressed with the whole implementation.

Similar Messages

  • Getting stack overflow exception whilst reading from HashMap

    hi,
    We are getting stack oveflow exception exception whilst reading from the HashMap.
    Following are few details about the code
    We have a swing based client and Session beans and Entity beans deployed on Weblogic Server.
    When the server is started, a session bean method queries to data base and creates a java object for each row in the data base.This java object is then stored in HashMap. These java objects have all get/set methods . and it has attributes of primitive data type as well as other java objects.This Hahsmap is then returned to client.
    When client calls this method and the method processes succesfuly , but when tries to return the HashMap, it gives Stack overflow exception.
    Looking at the stack trace i think this exception is thrown when the HashMap.readObject() methods is being invoked.
    does any body have any idea about this ? a quick help is much appriciated.

    Stack overflow is often caused by infinity loops No, an infinite loop would be like while (true) {
        // stuff
    } That doesn't cause stack overflow.
    or
    recursive method calls.Bingo.

  • Stack overflow exception when selecting the Organization tab on a contact card

    I have encountered a reproducible crash in the Lync 2013 client.  The crash happens after selecting the "Organization" tab when viewing a contact card.
    The crash appears to happen because of a stack overflow with MSO.DLL.  I have applied the latest hotfix for that module but the crash persists.
    Before I open a case with MSFT, can anyone offer any insight?  Perhaps this is being seen elsewhere?
    Exception Stack:
    SYMBOL_NAME:  mso!Ordinal3863+4970
    FOLLOWUP_NAME:  MachineOwner
    MODULE_NAME: MSO
    IMAGE_NAME:  MSO.DLL
    DEBUG_FLR_IMAGE_TIMESTAMP:  50ee6c2f
    FAILURE_BUCKET_ID:  STACK_OVERFLOW_c00000fd_MSO.DLL!Ordinal3863
    BUCKET_ID:  APPLICATION_FAULT_STACK_OVERFLOW_mso!Ordinal3863+4970
    WATSON_STAGEONE_URL: 
    http://watson.microsoft.com/StageOne/lync_exe/15_0_4420_1017/5067326f/bcryptprimitives_dll/6_1_7600_16385/4a5bd987/c00000fd/000048c0.htm?Retriage=1
    Followup: MachineOwner
    0:004> kvn 1000
     # ChildEBP RetAddr  Args to Child             
    00 042c314c 738d4863 128db2d0 00000000 00000000 bcryptprimitives!AesCtrRng_Generate+0x1e (FPO: [Non-Fpo])
    01 042c321c 738d47a4 128db2b8 1524cb1b 00000008 bcryptprimitives!MSCryptAesCtrGen+0x166 (FPO: [Non-Fpo])
    02 042c3248 72781e65 0c2c8ae8 1524cb1b 00000008 bcryptprimitives!MSCryptGenRandom+0xc9 (FPO: [Non-Fpo])
    03 042c3260 6b8c1de1 12811348 1524cb1b 00000008 bcrypt!BCryptGenRandom+0x5c (FPO: [Non-Fpo])
    04 042c3278 65daaa26 1524cb1b 00000008 042c32ac cryptdll!DefaultRngFn+0x21 (FPO: [Non-Fpo])
    05 042c3288 65db4a73 1524cb1b 00000008 00000000 kerberos!KerbRandomFill+0x10 (FPO: [Non-Fpo])
    06 042c32ac 65daa2ec 1524cb05 80000001 042c3484 kerberos!KerbMakeSignatureToken+0x4e8 (FPO: [Non-Fpo])
    07 042c341c 750df30c 128d8248 80000001 042c34a8 kerberos!SpSealMessage+0x3d7 (FPO: [Non-Fpo])
    08 042c343c 750e128c 070c6c80 80000001 042c34a8 sspicli!LsaSealMessage+0x6e (FPO: [Non-Fpo])
    09 042c3460 7707ad44 0c53adfc 80000001 042c34a8 sspicli!EncryptMessage+0x3e (FPO: [Non-Fpo])
    0a 042c34d0 7707abdc 1513b5f0 00000132 00000000 Wldap32!CryptStream::SignAndSealLdapStream+0x184 (FPO: [Non-Fpo])
    0b 042c3518 770745d6 1513b5f0 000000d7 00000006 Wldap32!CryptStream::LdapSendSsl+0x12b (FPO: [Non-Fpo])
    0c 042c3534 77078527 0c53af5c 1278cef8 00000000 Wldap32!LdapSend+0xd8 (FPO: [Non-Fpo])
    0d 042c3558 770787b2 12c79fa0 0c53ad78 12597998 Wldap32!SendLdapSearch+0x64a (FPO: [Non-Fpo])
    0e 042c3594 770a91f4 0c53ad78 152f06e4 00000000 Wldap32!LdapSearch+0x28f (FPO: [Non-Fpo])
    0f 042c35e0 585c882f 0c53afa4 152f06e4 00000000 Wldap32!ldap_search_extW+0x48 (FPO: [Non-Fpo])
    WARNING: Stack unwind information not available. Following frames may be wrong.
    10 042c3624 585d2b7c 00000000 402af114 152f06e4 MSO!Ordinal8903+0x4f04
    11 042c3734 585d30e0 152f06e4 042c3768 12ae9be0 MSO!Ordinal3863+0x43b6
    12 042c3aa8 585d3136 152f06e4 12ae9be0 0c385808 MSO!Ordinal3863+0x491a
    13 042c3e14 585d3136 152e4d94 12ae9be0 0c385808 MSO!Ordinal3863+0x4970
    14 042c4180 585d3136 152f0404 12ae9be0 0c385808 MSO!Ordinal3863+0x4970
    <SNIP>
    4b1 043bfb44 579e9c53 1293ddb0 043f7130 043bfb6c MSO!Ordinal2317+0x240
    4b2 043bfb54 579e9bf7 1293ddb8 12c54790 1293ddb8 MSO!Ordinal2317+0x12b
    4b3 043bfb6c 5778abcd 1293ddb8 12c54790 5777ccab MSO!Ordinal2317+0xcf
    4b4 043bfb9c 5777bc92 043bfc0c 043bfbf0 003602e0 MSO!Ordinal5372+0x66
    4b5 043bfbb4 57778a6f 043bfc0c 00000000 003602e0 MSO!Ordinal4578+0x1bc
    4b6 043bfbe8 577776fd 00000000 577776fd 043bfc0c MSO!Ordinal630+0x18ed
    4b7 043bfc3c 768033aa 003602e0 043bfc88 77a19ef2 MSO!Ordinal630+0x57b
    4b8 043bfc48 77a19ef2 003602e0 69d72777 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
    4b9 043bfc88 77a19ec5 577776a4 003602e0 ffffffff ntdll!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
    4ba 043bfca0 00000000 577776a4 003602e0 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
    0:004> lmivm mso
    start    end        module name
    57760000 58f92000   MSO        (export symbols)       MSO.DLL
        Symbol file: MSO.DLL
        Image path: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE15\MSO.DLL
        Image name: MSO.DLL
        Timestamp:        Thu Jan 10 01:22:23 2013 (50EE6C2F)
        CheckSum:         01833BC0
        ImageSize:        01832000
        File version:     15.0.4481.1000
        Product version:  15.0.4481.0
        File flags:       0 (Mask 3F)
        File OS:          40004 NT Win32
        File type:        2.0 Dll
        File date:        00000000.00000000
        Translations:     0000.04e4
        CompanyName:      Microsoft Corporation
        ProductName:      Microsoft Office 2013
        InternalName:     MSO
        OriginalFilename: MSO.DLL
        ProductVersion:   15.0.4481.1000
        FileVersion:      15.0.4481.1000
        FileDescription:  Microsoft Office 2013 component

    I actually think I may have figured this out.  I took a network trace during the crash.  What I found is that Lync is performing repeated LDAP searches over and over until it crashes from the stack overflow.  Digging into
    the searches, I found the same two user CN's being alternated one after another.
    It appears that this crash may be the result of a "Circular Reference" where the two users are each listed as the others manager in their user object.
    Example:
    User1: Manager = User2
    User2: Manager = User1
    Proving this as the cause will take me some additional time as these two users are at the top of the Org Chart.  :)
    I'll update this post with the results when I get them. 

  • Stack Overflow Exception in EJB Explorer

    Hello everyone!
    I have correct working EJB which returns in one method and JPA Entity that have bidirectional relationship with other entity. This relationship is @OneToMany and @ManyToOne on other side and all of the related objects are loaded before the end of the method. This EJB is working correctly when used with other components.
    I have problems testing this method in EJB Explorer utility that is part of the SAP NetWeaver Aplication Server Java. When i start this method it never finishes and later gets an stack overflow error. Trace is here:
    java.lang.RuntimeException: java.lang.StackOverflowError : null
      at java.lang.Class.getMethod0(Class.java:2670)
      at java.lang.Class.getMethod(Class.java:1603)
      at com.sap.ejbexplorer.business.invocation.impl.Structure.fillWith(Structure.java:213)
      at com.sap.ejbexplorer.business.invocation.impl.Structure.fillNestedStructureWith(Structure.java:314)
      at com.sap.ejbexplorer.business.invocation.impl.Structure.fillWith(Structure.java:202)
      at com.sap.ejbexplorer.business.invocation.impl.Structure.fillNestedStructureWith(Structure.java:287)
      at com.sap.ejbexplorer.business.invocation.impl.Structure.fillWith(Structure.java:234)
    Looks like EJB Explorer is trying to expand all returned objects. Then he gets into the unfinished loop because of the bidirectional relationship.
    We are using SAP NetWeaver 7.20 SP04.
    Is this error fixed in new version?
    Is there some configuration that fix this?
    Thank you for any response.

    Hi,
    is it just for the presence of the JUnit extension, or do you use this class in your Unit testing ?
    Frank
    Ps.: The JDeveloper 11 forum is JDeveloper and OC4J 11g Technology Preview

  • Stack overflow error with production release

    Hi,
    I am using Flex 4.5.1 and I am getting a weird error upon exporting a production release. Here is the stack trace:
    VerifyError: Error #1023: Stack overflow occurred.
              at spark.components.gridClasses::GridLayout/intializeGridVisualElement()
              at spark.components.gridClasses::GridLayout/layoutIndicator()
              at spark.components.gridClasses::GridLayout/layoutCaretIndicator()
              at spark.components.gridClasses::GridLayout/updateDisplayList()
              at spark.components.supportClasses::GroupBase/updateDisplayList()
              at spark.components::Group/updateDisplayList()
              at spark.components::Grid/updateDisplayList()
              at mx.core::UIComponent/validateDisplayList()
              at spark.components::Group/validateDisplayList()
              at mx.managers::LayoutManager/validateDisplayList()
              at mx.managers::LayoutManager/doPhasedInstantiation()
              at mx.managers::LayoutManager/doPhasedInstantiationCallback()
    As you can see there is no trace of our own classes anywhere. I don't get this error if I use the normal debug version. We are very close to going live and we can't use the debug version files as they are bulky and are increasing the initial load time of the application.
    Please help!
    Thanks.
    Manoj

    Hey I get this suddenly in an app that's been running and working fine.  We just updated with a release build for some other updates and I get this error.  Here's the context:
    I am using Flex 4.6, have a component that extends the Flex 3 AdvancedDataGrid for some lightweight customization of how column resising work.  The component is used in several of our apps.  But, for some reason, and with no code updates to this particular component in a while, when I click on a row in the grid, I get this stack overflow exception too.  The exact same stack trace as the one mentioned by the original poster.
    Anyone have a clue why I would be seeing "spark.components.gridClasses::..." in my stack trace to begin with when the component that is being clicked on is a Flex 3 AdvDataGrid component?  I've seen some mention of the compiler error that somehow bashes the stack under the perfect circumstances.  But, in our case, we've eliminated all of our own event handlers (click/etc) from the grid and we still get this error and only in the release build.  So, there's no way to change any of our code to fix it b/c none of our code is executing when the error occurs.
    This is very very odd stuff.  Any ideas???

  • Create Release IPA Stack Overflow

    Hello i have a little problem... we built an app wich has a video section.
    We took the videos (MP4) into the app over app publishing settings (checkmarking the files)...
    when i have about 6 videos it works well... when i inlclude more videos i get an error while generating the ipa... "map failed" ... i think an Stack Overflow? the main problem is that filesize of each video is not the only problem... i can convert the videos a little bit but when i have many videos i get the same problem because the WHOLE filesize is then too much...could this be really the reason for my error?? or do i have another problem?
    Any ideas how i can solve this problem??? I use flash builder 4.6

    Hey I get this suddenly in an app that's been running and working fine.  We just updated with a release build for some other updates and I get this error.  Here's the context:
    I am using Flex 4.6, have a component that extends the Flex 3 AdvancedDataGrid for some lightweight customization of how column resising work.  The component is used in several of our apps.  But, for some reason, and with no code updates to this particular component in a while, when I click on a row in the grid, I get this stack overflow exception too.  The exact same stack trace as the one mentioned by the original poster.
    Anyone have a clue why I would be seeing "spark.components.gridClasses::..." in my stack trace to begin with when the component that is being clicked on is a Flex 3 AdvDataGrid component?  I've seen some mention of the compiler error that somehow bashes the stack under the perfect circumstances.  But, in our case, we've eliminated all of our own event handlers (click/etc) from the grid and we still get this error and only in the release build.  So, there's no way to change any of our code to fix it b/c none of our code is executing when the error occurs.
    This is very very odd stuff.  Any ideas???

  • Bypassing cache = stack overflow

    Hi,
    I have the same problem as the guy who posted 2 days ago. I need to effectively bypass the cache due to updates from 'outside'. We already tried the option with 'Always Refresh' and 'Disable Cache Hits'. Unfortunately this results in a stack overflow exception. This is what probably happens:
    We have two classes User and UserRole. UserRole references User, User has a collection of UserRole instances, i.e. circular referencing. Both classes are configured to bypass the indentity cache. (A separate tool is used to manage users and user roles.) When trying to find one special User instance TopLink recurses back and forth between User and UserRole desperately trying to resolve all references ending up in a stack overflow exception.
    Any means to stop that behaviour?
    Regards

    Yeah, you shouldn't use both Always Refresh and Disable Cache Hits on both directions of a circular relationship. If you turn off the disable cache hits for the source class of the 1-M, it should be Ok.
    Disable Cache Hits tells TopLink to even go to the database for PK based queries, where normally it would just hit the cache, and this is getting called when setting up the back reference from the targets of the 1-M.
    My advice to customers is usually to ignore this Refreshing Cache Options feature in the Mapping Workbench, and explicitly do refreshing on a per-query as needed basis in code when you create your ReadObject/ReadAll query... That way you have a finer grained control over when to do refreshes. But, it's always, then no problems doing it in the MW...
    - Don

  • Stack overflow error while creating connection using Oracle10G dirver

    Hi,
    Our web application built on Servlets runs on the iPlanet web server (In solaris machine). Earlier we used JDK 1.5 update 6 with oracle 9i driver and now got migrated to JDK 1.5 update 10 with same driver. Everything went fine until we started testing the environment with oracle 10G driver. Java 1.5 update 10 with oracle 10G driver throws "Stack overflow error".
    Driver version is - 10.2.0.2.0
    This occurs only when I access the portal. When I created the single main program and try to run it in the solaris machine it works fine. But wen I try to access the portal keeping this driver under classpath, it fails. Please let me know if anyone have any clues.
    When I looked into it, I am able to find that the "stack overflow error" occurs at the point the code line DriverManager.Getconnection("url", "username", "pwd") executes.
    Thanks in advance
    below the stacktrace of the exception from webserver error log..
    06/Mar/2007:04:20:40] failure (10198):
    for host 202.54.182.136 trying to POST /wr/servlet/WorkRequest, service-j2ee reports: StandardWrapperValve[WorkRequest]: WEB2769: Allocate exception for servlet WorkRequest
    javax.servlet.ServletException: WEB2778: Servlet.init() for servlet WorkRequest threw exception
    at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:949)
    at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:658)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:244)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:209)
    at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)
    at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:161)
    at com.iplanet.ias.web.WebContainer.service(WebContainer.java:580)
    ----- Root Cause -----
    java.lang.StackOverflowError
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
    at java.lang.ClassLoader.loadClass(
    [06/Mar/2007:04:22:20] info (10198):
    CORE5073: Web server shutdown in progress
    [06/Mar/2007:04:22:21] info (14506):
    CORE1116: Sun ONE Web Server 6.1SP5 (64-Bit) B12/02/2005 04:37
    [06/Mar/2007:04:22:21] warning (14513):
    CORE1251: On group ls1, servername pstst42.pedc.sbc.com does not match subject "" of certificate Server-Cert.
    [06/Mar/2007:04:22:21] warning (14513):
    CORE1250: In secure virtual server https-vts, urlhost does not match subject "" of certificate Server-Cert.
    [06/Mar/2007:04:22:21] info (14513):
    CORE5076: Using [Java HotSpot(TM) 64-Bit Server VM, Version 1.5.0_06] from [Sun Microsystems Inc.]
    [06/Mar/2007:04:22:21] info (14513):
    WEB0100: Loading web module in virtual server [https-vts] at [servlet]
    [06/Mar/2007:04:22:21] info (14513):
    WEB0100: Loading web module in virtual server [https-vts] at [vts/servlet]
    [06/Mar/2007:04:22:21] info (14513):
    WEB0100: Loading web module in virtual server [https-vts] at [cron/servlet]
    [06/Mar/2007:04:22:21] info (14513):
    WEB0100: Loading web module in virtual server [https-vts] at [find/servlet]
    [06/Mar/2007:04:22:21] info (14513):
    WEB0100: Loading web module in virtual server [https-vts] at [cb/servlet]
    [06/Mar/2007:04:22:21] info (14513):
    WEB0100: Loading web module in virtual server [https-vts] at [wr/servlet]
    [06/Mar/2007:04:22:21] info (14513):
    WEB0100: Loading web module in virtual server [https-vts] at [search]
    [06/Mar/2007:04:22:25] info (14513):
    HTTP3072: [LS ls1] ready to accept requests
    [06/Mar/2007:04:22:25] info (14513):
    CORE3274: successful server startup
    Message was edited by:
    Nandakumar_s
    Message was edited by:
    Nandakumar_s

    Yes, request goes through connection pool but weird
    thing is application throws stack excatly where
    DriverManager.getConnection gets executed.
    Not weird at all.
    This is what I am guessing that you did. You changed the driver and some other stuff, like configuration information.
    Then when it blew up you tracked down in your code where you see the stack overflow. That happens to be on the connection line. That is not where the overflow 'occurs' - it merely represents where you saw it.
    That line however isn't using the oracle driver. What it is using is a connection pool of some sort. That connection pool is configured somewhere. And that configuration is self-referential (or maybe refers to a another driver which refers back to the original.)
    And that causes you stack over flow.

  • Stack Overflow Jrockit 1.4.2_08 JVM R24.5.0-61 ari-49095-20050826-1856-linu

    Hi All we are using jrockit on Linux, we have a cluster that consists of 2 machines and each machine has 2 managed servers. the dumnp always happens on the one of the managed servers on each machine.
    Initially the cluster had 2 managed servers , one on each server, of lately we added 2 more managed servers (one each on the machine).
    ===== BEGIN DUMP =============================================================
    JRockit dump produced after 0 days, 07:53:23 on Fri Aug 18 02:46:57 2006
    Additional information is available in:
    /usr/local/bea/user_projects/domains/cmstargetDomain/jrockit.11168.dump
    No core file will be created because core dumps have been
    disabled. To enable core dumping, try "ulimit -c unlimited"
    before starting JRockit again.
    If you see this dump, please open a support case with BEA and
    supply as much information as you can on your system setup and
    the program you were running. You can also search for solutions
    to your problem at http://forums.bea.com in
    the forum jrockit.developer.interest.general.
    Error code: 52
    Error Message: Stack overflow
    Signal info : si_signo=11, si_code=2
    Version : BEA WebLogic JRockit(TM) 1.4.2_08 JVM R24.5.0-61 ari-49095-20050826-1856-linux-ia32
    Threads / GC : Native Threads, GC strategy: parallel
    : mmHeap->data = 0x20000000, mmHeap->top = 0x40000000
    : mmStartCompaction = 0x2c800000, mmEndCompaction = 0x2f000000
    CPU : Intel Pentium 4 (EM64T)
    Number CPUs : 4
    Tot Phys Mem : 4127768576
    OS version : Red Hat Enterprise Linux ES release 3 (Taroon Update 4)
    Linux version 2.4.21-27.ELsmp ([email protected]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-47)) #1 SMP
    Wed Dec 1 21:59:02 EST 2004
    State : JVM is running
    Command Line : -Djava.class.path=/usr/local/bea/jrockit81sp4_142_08/lib/tools.jar:/usr/local/bea/weblogic81/server/lib/weblog
    ic_sp.jar:/usr/local/bea/weblogic81/server/lib/weblogic.jar::/usr/local/bea/weblogic81/common/eval/pointbase/lib/pbserver44.j
    ar:/usr/local/bea/weblogic81/common/eval/pointbase/lib/pbclient44.jar:/usr/local/bea/jrockit81sp4_142_08/jre/lib/rt.jar:/usr/
    local/bea/weblogic81/server/lib/webservices.jar::/opt/documentum/shared/config:/opt/documentum/shared/dctm.jar -Djrockit.laun
    cher.type=jrockit.shipment -Xms512m -Xmx512m -Dweblogic.Name=cmpa05Server02 -Dweblogic.management.username= -Dweblogic.manage
    ment.password= -Dweblogic.management.server=http://10.200.148.13:8001 -Djava.security.policy=/usr/local/bea/weblogic81/server
    /lib/weblogic.policy -Dsun.java.command=weblogic.Server
    Environment : JAVA_HOME=/usr/local/bea/jrockit81sp4_142_08, java.home=/usr/local/bea/jrockit81sp4_142_08/jre, java.class.pat
    h=/usr/local/bea/jrockit81sp4_142_08/lib/tools.jar:/usr/local/bea/weblogic81/server/lib/weblogic_sp.jar:/usr/local/bea/weblog
    ic81/server/lib/weblogic.jar::/usr/local/bea/weblogic81/common/eval/pointbase/lib/pbserver44.jar:/usr/local/bea/weblogic81/co
    mmon/eval/pointbase/lib/pbclient44.jar:/usr/local/bea/jrockit81sp4_142_08/jre/lib/rt.jar:/usr/local/bea/weblogic81/server/lib
    /webservices.jar::/opt/documentum/shared/config:/opt/documentum/shared/dctm.jar, java.library.path=/usr/local/bea/jrockit81sp
    4_142_08/jre/lib/i386/jrockit:/usr/local/bea/jrockit81sp4_142_08/jre/lib/i386:/usr/local/bea/jrockit81sp4_142_08/jre/../lib/i
    386:/opt/documentum/shared/dfc:/usr/local/bea/weblogic81/server/lib/linux/i686:/usr/local/bea/weblogic81/server/lib/linux/i68
    6/oci920_8
    C Heap : Good; no memory allocations have failed
    Registers (from context struct at 0x895716c/0x8957234):
    EAX = b4dd7c14 EBX = 08954fd8
    ECX = b4dba06c EDX = 226f5f20
    ESI = 08954ed0 EDI = 08954fd8
    ESP = b4db9fec EIP = b7374aa2
    EBP = b4dba000 EFL = 00010292
    CS = 0023 DS = 002b ES = 002b
    SS = 002b FS = 0033 GS = 0033
    Stack:
    b4db9fec :00000000 00000000 00000000 00000000 00000000 b4dba030
    b4dba004 :b7374b1f 08954fd8 00000000 00000000 00000000 089550e0
    b4dba01c :00000000 00000000 00000000 00000000 00000000 b4dba060
    b4dba034 :b7368b05 08954fd8 00000000 00000000 00000000 089550e0
    b4dba04c :b4dba068 226f5ab8 00000000 00000000 00000000 08954fd8
    b4dba064 :b6566d57 08955064 0808cba0 089550e0 00000000 226f5050
    b4dba07c :08954fd8 0000020c 35a893b0 35a893c8 b6566da8 b6f4d8e0
    b4dba094 :226f5ab8 08954ed0 226f5f20 b65670b2 00000248 00000234
    b4dba0ac :af903372 00000234 b7368b2d 0000008d 00000000 226f5ab8
    b4dba0c4 :00000000 b4dba108 08954fd8 226f53c8 acb2b38e 226f53f0
    b4dba0dc :3be87630 35a893b0 35a893b0 35a893b0 af904a36 b4dba130
    b4dba0f4 :201aeb58 b4dba134 00000000 00000004 00000000 08954fd8
    b4dba10c :b4dba1d0 08954ed0 201aeb58 35a893c8 29cbd300 089550e0
    b4dba124 :0000008d 00000000 226f5ab8 0000008d 00000000 af904c85
    b4dba13c :226f5ab8 08954fd8 b4dba154 acb2b43e b6577440 b65684d8
    b4dba154 :b6577430 b7359a4d b4dbb3cb 00000000 00000000 b4dba1f4
    b4dba16c :08955064 b6017da8 b6f15ab8 08954fd8 08955064 b6f15ab8
    b4dba184 :b4dba1b4 b732e61a b6f15ab8 b4dba1b0 08955064 00000001
    b4dba19c :b6f15ab8 b4dba1f0 b4dba1f4 b733e775 08955064 b4dba1ec
    b4dba1b4 :b4dba154 00000000 00000000 00000000 00000000 00000000
    b4dba1cc :00000000 226f5cc0 b4dba154 b4dba154 08954fd8 b4dba210
    b4dba1e4 :b6577430 b65684a0 00000000 b4dbb3cb b4dba234 b733e931
    b4dba1fc :08955064 080f7bd0 b6017da8 089550dc b4dba288 b7359550
    b4dba214 :b4dba26c b4dba238 08955064 089550dc b4dba3b4 00000000
    b4dba22c :00000000 080f7bd0 b4dba274 b733f146 08955064 b6f15ab8
    b4dba244 :089550dc b4dba288 b7359550 00000000 b4dba26c b4dba27c
    b4dba25c :08955064 00000004 00000000 08954fd8 226f5400 089550e0
    b4dba274 :b4dba2a4 b733ed68 08955064 089550dc b6f15ab8 b4dba2b8
    b4dba28c :08955064 089550e0 b4dba3b4 08954fd8 089550dc 08955064
    b4dba2a4 :b4dba2e4 b7341e69 08955064 089550dc b6f15ab8 00000002
    b4dba2bc :08955064 089550dc 00000000 b733b94c 08955064 b4dba310
    b4dba2d4 :00000000 089550d4 00000008 00000004 b4dba314 b7341d9a
    b4dba2ec :08955064 089550dc b4dba3b4 00000fff 089550dc 00000000
    b4dba304 :08954fd8 b4dba348 b753045c 089550dc b4dbb3b4 b73505d5
    b4dba31c :08955064 089550dc b4dba3b4 00000fff 089550dc b4dbb3bc
    b4dba334 :226f5948 b4dba378 b7368b2d 08954fd8 b4dba3b4 00000000
    b4dba34c :b7368b24 b4dba390 b73072bb 08954ed0 29cc68b8 b4dba380
    b4dba364 :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba37c :00000000 b4dba3c0 b7368b2d 08954fd8 00000005 b4dba3c0
    b4dba394 :b7368b24 08954ed0 0000008d 35a893c8 29cc7b00 089550e0
    b4dba3ac :b4dba3c8 00000000 7273752f 636f6c2f 622f6c61 752f6165
    b4dba3c4 :5f726573 6a6f7270 73746365 6d6f642f 736e6961 736d632f
    b4dba3dc :67726174 6f447465 6e69616d 706d632f 53353061 65767265
    b4dba3f4 :2f323072 67617473 6d632f65 72657373 65636976 736d632f
    b4dba40c :76726573 2e656369 2f726177 2d424557 2f464e49 73616c63
    b4dba424 :2f736573 69646e6a 6f72702e 74726570 00736569 b4dba458
    b4dba43c :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba454 :00000000 b4dba498 b7368b2d 08954fd8 00000005 b4dba498
    b4dba46c :b7368b24 08954ed0 0000008d 35a893c8 29ccb300 089550e0
    b4dba484 :b4dba4a0 00000000 29ccb2d8 b4dba4d0 b73072bb 08954ed0
    b4dba49c :0000008d b4dba4c0 b7374b02 08954fd8 08954ed0 00000000
    b4dba4b4 :08954fd8 b4dba4f8 b73072bb 08954ed0 b7368b2d b4dba4e8
    b4dba4cc :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba4e4 :00000000 b4dba528 b7368b2d 08954fd8 00000005 00000000
    b4dba4fc :b7368b24 b4dba540 b73072bb 08954ed0 29ccd8b8 b4dba530
    b4dba514 :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba52c :00000000 b4dba570 b7368b2d 08954fd8 00000005 b4dba570
    b4dba544 :b7368b24 08954ed0 0000008d 35a893c8 29cceb00 089550e0
    b4dba55c :b4dba578 00000000 29ccead8 b4dba5a8 b73072bb 08954ed0
    b4dba574 :0000008d b4dba598 b7374b02 08954fd8 08954ed0 00000000
    b4dba58c :08954fd8 b4dba5d0 b73072bb 08954ed0 b7368b2d b4dba5c0
    b4dba5a4 :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba5bc :00000000 b4dba600 b7368b2d 08954fd8 00000005 00000000
    b4dba5d4 :b7368b24 b4dba618 b73072bb 08954ed0 29cd10b8 b4dba608
    b4dba5ec :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba604 :00000000 b4dba648 b7368b2d 08954fd8 00000005 b4dba648
    b4dba61c :b7368b24 08954ed0 0000008d 35a893c8 29cd2300 089550e0
    b4dba634 :b4dba650 00000000 29cd22d8 b4dba680 b73072bb 08954ed0
    b4dba64c :0000008d b4dba670 b7374b02 08954fd8 08954ed0 00000000
    b4dba664 :08954fd8 b4dba6a8 b73072bb 08954ed0 b7368b2d b4dba698
    b4dba67c :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0b4dba694 :00000000 b4dba6d8 b7368b2d 08954fd8 00000005 00000000
    b4dba6ac :b7368b24 b4dba6f0 b73072bb 08954ed0 29cd48b8 b4dba6e0
    b4dba6c4 :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba6dc :00000000 b4dba720 b7368b2d 08954fd8 00000005 b4dba720
    b4dba6f4 :b7368b24 08954ed0 0000008d 35a893c8 29cd5b00 089550e0
    b4dba70c :b4dba728 00000000 29cd5ad8 b4dba758 b73072bb 08954ed0
    b4dba724 :0000008d b4dba748 b7374b02 08954fd8 08954ed0 00000000
    b4dba73c :08954fd8 b4dba780 b73072bb 08954ed0 b7368b2d b4dba770
    b4dba754 :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba76c :00000000 b4dba7b0 b7368b2d 08954fd8 00000005 00000000
    b4dba784 :b7368b24 b4dba7c8 b73072bb 08954ed0 29cd80b8 b4dba7b8
    b4dba79c :b7374b02 08954fd8 08954ed0 08954fd8 000000a0 089550e0
    b4dba7b4 :00000000 b4dba7f8 b7368b2d 08954fd8 00000005 b4dba7f8
    b4dba7cc :b7368b24 08954ed0 0000008d 35a893c8 29cd9300 089550e0
    b4dba7e4 :b4dba800 00000000 29cd92d8 b4dba830 b73072bb 08954ed0
    Code:
    b73749a2 :85ffffc0 e84d74c0 0000a0aa d689c389 e868006a 56000003
    b73749ba :c800e853 c4830000 fab4a310 1589b744 b744fab8 ffa35de8
    b73749d2 :bac189ff 000003e8 f799d089 99c189f9 53565052 00c7d5e8
    b73749ea :faaca300 1589b744 b744fab0 5be8658d 5dec895e 895590c3
    b7374a02 :10ec83e5 5d8b5356 f4c48308 8954e853 c689ffff 53f4c483
    b7374a1a :ff89a9e8 8df089ff 5e5be865 c35dec89 8955f689 5d8b53e5
    b7374a32 :0c4d8b08 8910558b b10ff0c8 c2890c53 940fca39 c0b60fc0
    b7374a4a :5dec895b 895590c3 5d8b53e5 0c4d8b08 8910558b b10ff0c8
    b7374a62 :c2891053 940fca39 c0b60fc0 5dec895b 895590c3 08558be5
    b7374a7a :8b104d8b 0ff00c45 890c4ab1 5dec89c2 895590c3 08458be5
    b7374a92 :8b5dec89 fc240440 895590c3 14ec83e5 085d8b53 8508438b
    b7374aaa :831374c0 e853f4c4 ffffc8da 000843c7 83000000 7b8310c4
    b7374ac2 :07740024 002443c7 83000000 44fa943d 097400b7 53f4c483
    b7374ada :ff9e55e8 e85d8bff c35dec89 8955f689 08ec83e5 8508458b
    b7374af2 :800d74c0 83fe0460 e850f4c4 ffffff9a c35dec89 8955f689
    b7374b0a :14ec83e5 085d8b53 3a74db85 53f4c483 ffff7de8 10c483ff
    b7374b22 :01044b80 07581d39 2274b746 fa943d83 7400b744 f4c48319
    b7374b3a :ffa8e853 c483ffff 044b8010 943d8301 00b744fa 5d8be775
    b7374b52 :5dec89e8 895590c3 08458be5 0e75c085 000001b8 8d0feb00
    b7374b6a :000026b4 408b0000 83013404 ec8901e0 8955c35d 10ec83e5
    b7374b82 :758b5356 047e8308 83437500 026af8c4 1bece856 c3890000
    b7374b9a :83f4c483 e853f4c4 ffff7e6e 3a30e850 c483fff0 74c08530
    Loaded modules:
    (* denotes the module causing the exception)
    0x08048000-0x0804ce46 /usr/local/bea/jrockit81sp4_142_08/bin/java
    0xb75e5000-0xb75e561b /etc/libcwait.so
    0xb75bf000-0xb75cb931 /lib/tls/libpthread.so.0
    0xb759d000-0xb75bde5f /lib/tls/libm.so.6
    0xb759a000-0xb759be23 /lib/libdl.so.2
    0xb7462000-0xb7593eaf /lib/tls/libc.so.6
    0xb75e9000-0xb75fdc8b /lib/ld-linux.so.2
    0xb7228000-0xb73feeef* /usr/local/bea/jrockit81sp4_142_08/jre/lib/i386/jrockit/libjvm.so
    0xb7005000-0xb700f2df /lib/libnss_files.so.2
    0xb66af000-0xb66befa5 /usr/local/bea/jrockit81sp4_142_08/jre/lib/i386/libverify.so
    0xb6681000-0xb66a0a0f /usr/local/bea/jrockit81sp4_142_08/jre/lib/i386/libjava.so
    0xb6656000-0xb66670eb /lib/libnsl.so.1
    0xb5321000-0xb5322705 /usr/local/bea/weblogic81/server/lib/linux/i686/libweblogicunix1.so
    0xb4a81000-0xb4a82eff /usr/local/bea/weblogic81/server/lib/linux/i686/libmuxer.so
    0xb3ebb000-0xb3ebe5c1 /usr/local/bea/jrockit81sp4_142_08/jre/lib/i386/libioser12.so
    0xb0fd5000-0xb0fd8133 /lib/libnss_dns.so.2
    0xb0fc3000-0xb0fd179f /lib/libresolv.so.2
    0xaeeaa000-0xaf4293ca /opt/documentum/shared/dfc/libdmcl40.so
    0xaee67000-0xaee6b1fb /lib/libcrypt.so.1
    0xaedb4000-0xaee5c9eb /usr/lib/libstdc++.so.5
    0xaedab000-0xaedb2813 /lib/libgcc_s.so.1
    Java Thread ID = 0x00001b80, lastJavaFrame = 0xb4dba06c, Name = ExecuteThread: '41' for queue: 'weblogic.kernel.Default'
    Thread Stack Trace:
    at tsiGCStateChanged+6()@0xb7374aa2
    at tsDisableGC+23()@0xb7374b1f
    at RJNI_jrockit_vm_MemSystem_getMoreTLAMemory+37()@0xb7368b05
    at jrockit/vm/MemSystem.getMoreTLAMemory(Native Method)@0xb6566d10
    at jrockit/vm/MemSystem.getMoreTLAMemoryWrapper(Native Method)@0xb6566da8
    at jrockit/vm/MemSystem.allocArray1(Native Method)@0xb65670b2
    at java/lang/StringCoding$CharsetSE.encode(Optimized Method)@0xaf903372
    at java/lang/StringCoding.encode(Optimized Method)@0xaf904a36
    at java/lang/StringCoding$DefaultEncoder.encode(Optimized Method)@0xaf904c85
    at java/lang/StringCoding.encode(Optimized Method)@0xacb2b43e
    at java/lang/String.getBytes(Unknown Source)@0xb6577440
    at java/io/UnixFileSystem.getBooleanAttributes0(Native Method)@0xb657f0e0
    at java/io/UnixFileSystem.getBooleanAttributes(Unknown Source)@0xb657f17f
    at weblogic/servlet/internal/WarClassFinder.getSource(Optimized Method)@0xacb3d89b
    at weblogic/servlet/internal/WarClassFinder.getSources(WarClassFinder.java:106)@0xb45c4f12
    at weblogic/utils/classloaders/MultiClassFinder.getSources(MultiClassFinder.java:97)@0xb45c4eaa
    at weblogic/utils/classloaders/MultiClassFinder.getSources(MultiClassFinder.java:89)@0xb45c4e0b

    Did a quick check and can't find anything obvious. Some tips:
    1) You are running on RHEL3u4, which is formally an "unsupported configuration". You should upgrade the OS to u5 or later. There are known I/O issues in RHEL3u4 and earlier. I don't think it has anything to do with your crash, but better safe than sorry. See http://e-docs.bea.com/jrockit/jrdocs/suppPlat/supp_142.html
    2) You may want to try the latest JRockit update, which you can find here: http://commerce.bea.com/products/weblogicjrockit/1.4.2/142_x.jsp
    3) If neither of the above helps, or you can't make an upgrade in your production environment, open a ticket with BEA Support. Before you do that, try to reproduce the crash after setting "ulimit -c unlimited" in the shell so that you get a proper core file.

  • Stack Overflow Error for JNI program with Jdk1.3

    I wrote a JNI wrapper for a third party sofware (written in C) to use some exported functions provided. My program runs fine when using Sun JDK1.2.2, but I got the following error when using Jdk1.3 to run the program (It's a runtime error, only the version of runtime virtual machine matters.)
    # An EXCEPTION_STACK_OVERFLOW exception has been detected in native code outside
    the VM.
    # Program counter=0x9073337
    A stack overflow was encountered at address 0x09073337.
    I tried IBM jdk 1.2.2, it gave me a similar error complaining about the stack overflow error.
    The vendor of the third party software denies any wrong doing in their code and I don't have their source code. A test client (simulate the Java client) I wrote in C works perfectly fine and as I mentioned earlier the same java progarm runs OK with jdk 1.2.2, without any change to my system stack size. Does any body know what this is about and the solution for this?
    Thanks!
    My email: [email protected]

    I had the same exception occur in my JNI code and I have some advice on things to look for.
    Symptoms: The C++ code runs fine when called in an native executable but when it is wrapped by a JNI call inside a DLL you get the following exception:
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : EXCEPTION_STACK_OVERFLOW occurred at PC=0x100d72e5
    Function name=_chkstk
    The address will be different of course.
    In my tests I isolated the problem to an allocation of a char array like so at the top of one of my wrapped C++ methods:
    char buf[650000];
    As you see this code is requesting 650000 bytes of stack memory. When run in a native executable there was no problem but when I ran it wrapped in the JNI call it blew up.
    Conclusion: There is a much smaller stack space when using JNI OR the added overhead of my JNI wrapper exhausted the available stack space OR this is a stack space issue related to DLLs.
    Hope this helps. Anyone with insight on this please put in your 2 cents.

  • Stack Overflow

    Hi experts,
    My application is showing stack overflow after showing nullpointer exception. If want more details about code, let me know.
    Thanks in advance

    hello,
    unfortunatly there is a bug in the delimited output, that restricts the length of the output due to a resource problem (Bug:1211760). please contact oracle support services for further details.
    regards,
    the oracle reports team

  • Stack overflow in JNI call

    Hi,
    I am doing a wrapper with JNI for a Windows library of image compression. I have a test program running correctly in C. This program compress data and it can move a lot of memory. If I call this program from a JNI functions I obtain a JNI error:
    An unrecoverable stack overflow has occurred.
    An unexpected exception has been detected in native code outside the VM.
    Unexpected Signal : EXCEPTION_STACK_OVERFLOW (0xc00000fd) occurred at PC=0x5FF88497
    Function=unpack_data+0x189D7
    Library=C:\WINDOWS\system32\NCSEcw.dll
    This error is produce inside my compression library. I try to adjust the parameters (-Xms -Xmx -Xss) of the JVM but in any case before the process ends it shows this exception. I have done other JNI interfaces and I never found with this problem before. Can anybody help me?
    Thanks in advance.

    I found in this forum a piece of code with a same kind problem but It is simpler than mine. I have proved this program in Windows and it produce the same error. In Linux it runs but if I enlarge the array largebuf it ends with the same error. In Linux I can reserve until 2 MB (in windows +-256K). Is there any way to increase the stack size in a jni call?.
    #include <stdio.h>
    #include <jni.h>
    #include "test.h"
    int myprint2(int a, int b){
         char extrabuf[100];
         printf("got here next\n");
         extrabuf;
         return 0;
    int myprint(int a, int b){
         char largebuf[260000];
         printf("got here\n");
         myprint2(1,1);
         largebuf;
         return 0;
    JNIEXPORT jint JNICALL Java_test_init(JNIEnv *env, jobject obj){
         myprint(1,1);
         return 1;
    test.java
    public class test{
         public native int init();
         public static void main(String []args){
              new test();
         public test(){
              System.loadLibrary("Nat");
              System.out.println(this.init());
    }

  • Regex gurus: Intermittent stack overflow from Matcher?

    I've been using the following code to grep out links from <a> tags in html. For some pages it is throwing stack overflows from within the pattern matcher class. I am wondering, is there a better way to be doing this, or did I make some kind of mistake that is causing this to happen? Any help or advice would be greatly appreciated.
        private static final String matchATags    = "(?i)<a(.|\\n)*?>";
        private static final String matchHREFPre  = "(?i)\\A(.|\n)*HREF\\s*=\\s*\"";
        private static final String matchHREFPost = "\"(.|\n)*$";
        private static final Pattern tagPattern = Pattern.compile(matchATags);
        protected List<String>
        getLinkText(
                String text
            if (text == null)
                throw new NullPointerException("null text");
            Matcher matcher = tagPattern.matcher(text);
            ArrayList<String> linkList = new ArrayList<String>();
            while (matcher.find()){
                String link = text.substring(matcher.start(), matcher.end());
                link = link.replaceAll(matchHREFPre, "");
                link = link.replaceAll(matchHREFPost, "");
                linkList.add(link);
            return linkList;
        }Here is a trace of the exception
    Parsing error scanning site http://www.amazon.com
    Error parsing http://www.amazon.com/exec/obidos/ASIN/0201752808/xeo
    Caused by java.lang.StackOverflowError
    java.lang.StackOverflowError
            at java.util.regex.Pattern$Branch.match(Pattern.java:3998)
            at java.util.regex.Pattern$GroupHead.match(Pattern.java:4052)
            at java.util.regex.Pattern$LazyLoop.match(Pattern.java:4241)
            at java.util.regex.Pattern$GroupTail.match(Pattern.java:4111)
            at java.util.regex.Pattern$BranchConn.match(Pattern.java:3962)
            at java.util.regex.Pattern$CharProperty.match(Pattern.java:3314)
            at java.util.regex.Pattern$Branch.match(Pattern.java:3998)
            at java.util.regex.Pattern$GroupHead.match(Pattern.java:4052)
            at java.util.regex.Pattern$LazyLoop.match(Pattern.java:4241)
            at java.util.regex.Pattern$GroupTail.match(Pattern.java:4111)
            at java.util.regex.Pattern$BranchConn.match(Pattern.java:3962)
            at java.util.regex.Pattern$CharProperty.match(Pattern.java:3314)
            at java.util.regex.Pattern$Branch.match(Pattern.java:3998)
          ...

    Never do this in a regex: "(.|\n)"  // WRONG If you want to match any character including line separators, use the dot in DOTALL mode: "(?s)." If there are characters you don't want to match, you can use a negated character class. In this case, you probably don't want to match angle brackets, so you could use this: "[^<>]" The way you're doing it (alternation) is extremely inefficient. Also, you aren't allowing for other kinds of line separator, like "\r\n" (DOS) and "\r" (older Mac OS). But if you do it the right way, you don't need to worry about that.

  • CE10, RAS 10: Stack overflow at line

    I am using Crystal 10, RAS 10 using Crystal Interactive Viewer. The error occurs when closing the viewer window.
    I receive a java alert: "Stack Overflow at line: 63"
    When I debugged I fount the error in the rendered javascript.
    The debugger stopped on this line: CR_oldOnunload_182861812.apply(this, arguments);
    I have found no help so far in getting rid of this error. Since this is rendered by Crystal I have no access to this code.

    There's no way to modify an internal JavaScript within the viewer - does this exception also appear if you try viewing a report using ePortfolio Lite (the sample portal)? 
    The specific JavaScript is trying to invoke some cleanup after the browser is closed.
    Are you on the latest Service Pack for Crystal 10?
    Sincerely,
    Ted Ueda

  • CE 10: Stack overflow at line

    I am using Crystal 10, RAS 10 using Crystal Interactive Viewer.  The error occurs when closing the viewer
    window.
    I receive a java alert: "Stack Overflow at line: 63"
    When I debugged I found the error in the rendered javascript. 
    The debugger stopped on this line: CR_oldOnunload_182861812.apply(this, arguments);
    I have found no help so far in getting rid of this error.  Since this is rendered by Crystal I have no
    access to this code.

    There's no way to modify an internal JavaScript within the viewer - does this exception also appear if you try viewing a report using ePortfolio Lite (the sample portal)? 
    The specific JavaScript is trying to invoke some cleanup after the browser is closed.
    Are you on the latest Service Pack for Crystal 10?
    Sincerely,
    Ted Ueda

Maybe you are looking for

  • Hp officejet pro l7590 with blinking memory card error message

    My all-in-one printer constantly blinks the yellow exclamation point and has the message Memory Card Error for no apparent reason.  I have not used a memory card.  It just decided to show the message and blink.  I turned it off and on again, with no

  • Itunes will not sync photos to ipad 3 properly

    Problems I've had since ipad 3: I download and install latest itunes i tell it to restore from backup of my ipad 2 - it fails, it simply does not give me the choice to pick my ipad 2 restore, so i end up doing new setup. i tell itunes to slectively b

  • Registry settings are missing

    The following is the message I am getting when I start Itunes. I have remove and reinstall itunes to no avail please help daughter got new ipod and wants to play with it. "The registry settings used by itunes fot importing and burning cds and DVD are

  • Request for TERMINAL (EXCEPT WHEN) Code

    Hello, I am using Terminal to set up and auto bcc address to my wife on our business account. I am using: defaults write com.apple.mail UserHeaders '{"bcc"="[email protected]";}' What is the code in Terminal when I want to add {except when "To"="[ema

  • HT4623 unable to restore ipad mini, as its showing enter passcode

    i have Ipad mini, in that some one putted the passcode and when i was trying to restore the ipad connecting to Itunes, in that time it is showing  " enter your passcode to restore the Ipad? can  you please help me how to restore this one, quick regar