Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <1137818247.1142263065460.JavaMail.jira@ajax>
Date: Mon, 13 Mar 2006 15:17:45 +0000 (GMT)
From: "Simone Gianni (JIRA)" <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-1790) VerifyException "Attempt to split
 long or double on the stack" in javaflow
In-Reply-To: <817548483.1141396962267.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/COCOON-1790?page=comments#action_12370191 ] 

Simone Gianni commented on COCOON-1790:
---------------------------------------

Trying to understand what happens here (read: studying BCEL and BRAKES) i noticed that all "new" instructions are removed (in the rewrite method). I suppose they are moved somewhere somehow, and maybe that's the point where a check on the argument size is probabily missing, but i can't find where this happens. 


> VerifyException "Attempt to split long or double on the stack" in javaflow
> --------------------------------------------------------------------------
>
>          Key: COCOON-1790
>          URL: http://issues.apache.org/jira/browse/COCOON-1790
>      Project: Cocoon
>         Type: Bug
>   Components: Blocks: Java Flow
>     Versions: 2.1.9-dev (current SVN)
>     Reporter: Simone Gianni

>
> When writing code like this :
> long time = System.currentTimeMillis();
> Date date = new Date(time);
> the given exception is thrown. It's a validation exception.  This happens when a long (maybe also a double?) is used in a constructor (not in a function call). The following code is a workaround :
> Date date = new Date();
> date.setTime(time);
> but can be used only when the object we are instantiating have a getter as an alternative to the constructor parameter.
> I'm having this problem with a fresh (yesterday) checkout of cocoon 2.1.X branch. Don't know yet if this apply to other versions of cocoon. I'm using Blackdown-1.4.2-02 on a 2.6.12-gentoo-r6 linux machine.
> Googling around it seems that this exception is raised when the data type in a pop2 JVM instruction is not correct. I think this is one of the side-effects of the javaflow BCEL manipulations, but I'm not skilled enought on BCEL and similar stuff to even think of a possible solution.
> The exception is raised loading the javaflow class, so it will prevent the entire flow (and not only the affected method) to be used. Also, the exception will just tell you that the class is invalid, and not point you to the place in code where this long is used in a constructor, so you'll have to spot it by hand. 
> I can produce a test case to try to narrow it down, but the given 3 lines of code are enought to produce the error in my javaflows.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira