keyproject / key Goto Github PK
View Code? Open in Web Editor NEWKeY Theorem Prover for Deductive Java Verification
Home Page: https://key-project.org
License: Other
KeY Theorem Prover for Deductive Java Verification
Home Page: https://key-project.org
License: Other
This issue was created at git.key-project.org where the discussions are preserved.
For a code fragment such as
/*@ public normal_behavior
@ ensures true;
(at)*/
public static int fib(int n) {
int k0 = 1; int k1 = 1;
//@ ghost int k0_old = k0;
//@ ghost int k1_old = k1;
/*@ loop_invariant
@ n >= 2 ==> (
@ i <= n + 1 &&
@ k1 == k1_old + k0_old
@ );
@ decreases n-i+1;
@ assignable \nothing;
(at)*/
for (int i = 2; i <= n; i++) {
int tmp = k1;
k1 = k0 + k1;
k0 = tmp;
//@ set k0_old = k0;
//@ set k1_old = k1;
}
return k1;
}
...KeY adds the Java statements resulting from setting the ghosts to the wrong places, that is outside the for loop and directly before the return:
for (int i = 2; i<=_n; i++) {
int tmp = k1;
k1=k0+k1;
k0=tmp;
}
k0_old=k0;
k1_old=k1;
I understand that this is probably due to the fact that Recoder needs a statement to assign comments to, and that the next statement after the setters is the return statement, but in any case that is undesired behavior, even more so since a block is left.
Information:
This issue was created at git.key-project.org where the discussions are preserved.
When KeY encounters a non-trivial (i.e. neither true nor false) diverges clause,
it creates two contracts: one with <>- and one with []-modality.The negation of the diverges condition is added as an assumption to the
<> contract, but no assumption is made for the [] case.This implies that the cases proved in <> need to repeated in [].
Adding another assumption would reduce verification effort in such cases.
Load the following class into KeY
class A {
boolean div, post;
/*@ diverges div;
@ ensures post;*/
void m() {}
}
you will get 2 proof obligations which read (essentially)
!div -> <m()> post
and
[m()] post
The latter should be
div -> [m()] post
(at)grahl at 2014-10-29
An alternative PO would be [m()]post & (!div -> <m()>true). This is equivalent to the two above and easier to prove than the current version (but maybe not easier than Mattias' suggestion).
This formulation reflects more the intuition behind diverges. But Mattias' suggestion is better for proving, since it provides usable DL contracts (with nontrivial postconditions).
(at)mulbrich -- (NEW_BUG
) 2014-10-28
(at)grahl -- (BUGNOTE_ADDED
) 2014-10-29
(at)grahl -- (BUGNOTE_UPDATED
) 2014-10-29
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-17
Submitted on: 2002-05-21 by (at)klebanov
Updated: 2002-05-27
Assigned to: (at)rbubel
Standalone prover. Man clicke auf den "Fenster schliessen"-Knopf des Windowmanagers. Es kommt die Abfrage "Exit: Are you sure?". Nein anclicken. Das Fesnster verschwindet trotzdem. Das Programm läuft dabei weiter.
(at)rbubel at 2002-05-24
Abweichendes Verhalten beim Schliessen von Fenstern. Nach Dokumentation von WindowAdapter wird das Fenster beim Erhalt eines WindowClosing Events nicht geschlossen, sofern es nicht im Listener explizit herbeigefuehrt wird.
Das stimmte so nur beschraenkt, in JFrame und Unterklassen wird das Verhalten beim erhalt eines solchen Events durch das Setzen von setDefaultCloseOperation bestimmt, das natuerlich Standardmaessig nicht auf Ignorieren(wie es der ursprgl. Dokumentation entsprechen wuerde) sondern auf Schliessen eingestellt ist.
Fixed in v0.320
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-977
Submitted on: 2010-04-05 by (at)mbender
Updated: 2013-01-18
Assigned to: (at)rbubel
Hitting CTRL+w, CTRL+q, CTRL+o and CTRL+e works, but CTRL+r does nothing for me
Start KeY, hit CTRL+r
(at)rbubel at 2010-04-05
As it works for me, can anyone confirm this bug?
(at)Markus: Do you have an entry in "Recent Files"? Does the reload button in the toolbar work?
(at)mbender at 2010-04-05
Yes and yes.
There are files in 'Recent Files'. And the reload button in the toolbar as well as the entry 'Reload' in the 'Files'-menu work fine for me.
(at)rbubel at 2010-04-05
Ok, the problem was that CTRL+R was assigned twice once to "Reload" and once to "Proof Reuse". As "Proof Reuse" was first, I changed the reload to F5.
(at)rbubel at 2010-04-05
Fixed in c04cc5f
Reassigned reload to F5 to avoid clash with Proof Reuse accelerator.
(at)klebanov at 2010-04-05
The proof reuse hotkey is not public - we can have Ctrl-R for reload. Go ahead and change it.
(at)rbubel at 2010-04-05
changed:
Reload->MenuShortCutKey + R
Reuse -> Alt + R[MenuShortCutKey ->
CTRL: Linux (+ Windows?)
CMD: MacOSX
(at)mbender -- (NEW_BUG
) 2010-04-05
(at)rbubel -- (BUGNOTE_ADDED
) 2010-04-05
(at)mbender -- (BUGNOTE_ADDED
) 2010-04-05
(at)rbubel -- (BUGNOTE_ADDED
) 2010-04-05
(at)rbubel -- (BUGNOTE_ADDED
) 2010-04-05
(at)rbubel -- (NORMAL_TYPE
) 2010-04-05
(at)rbubel -- (NORMAL_TYPE
) 2010-04-05
(at)rbubel -- (NORMAL_TYPE
) 2010-04-05
(at)klebanov -- (BUGNOTE_ADDED
) 2010-04-05
(at)rbubel -- (BUGNOTE_ADDED
) 2010-04-05
(at)grahl -- (NORMAL_TYPE
) 2013-01-18
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-731
Submitted on: 2006-10-13 by (at)pruemmer
Updated: 2006-12-17
Assigned to: (at)bweiss
When using a DL method contract (i.e., instead of expanding a method invocation) symbols ...(at)pre are introduced, but are not added to the functions namespace and cannot be entered/parsed in the instantiation dialog. A further problem seems to be that the names of such symbols are not made unique in a proper way, when using the same contract more than once multiple symbols ...(at)pre with the same name will be introduced.
(at)rbubel at 2006-10-26
The first part of the bug (symbols not in namespace) has been fixed by Benjamins latest checkin.
edited on: 26-Oct-06 16:23
(at)pruemmer at 2006-12-07
fix is mandatory for 1.0
(at)bweiss at 2006-12-11
The second part (unique naming) apparently also has been fixed somewhere along the way. However, the introduced names of the form "name(at)pre1", "name(at)pre2", ... can't be parsed. As I didn't feel like changing the parser, I just changed the syntax to "nameAtPre1", "nameAtPre2",... in 0.2411.
Also, the symbols which were added to the functions namespace were not the same symbols which were actually used in the sequent. This is fixed in 0.2411, too.
(at)pruemmer at 2006-12-12
Thanks for fixing the bug and sorry that I just found a further place where the parsing does not work: when I start a correctness proof for a DL method contract (using the DL method contract browser), the (at)pre symbols used in the proof obligation can lead to unparseable formulas.
To reproduce this, load the file examples/java_dl/DLContractChooser/example.key, choose the "twenty" contract, and then try to cut in a formula containing the symbol MyClass::a(at)pre
(at)bweiss at 2006-12-13
Yes, and the same thing used to happen for OCL proof obligations, too. It's fixed in 0.2413.
(at)pruemmer -- (NEW_BUG
) 2006-10-13
(at)rbubel -- (BUGNOTE_ADDED
) 2006-10-26
(at)rbubel -- (BUGNOTE_UPDATED
) 2006-10-26
(at)pruemmer -- (BUGNOTE_ADDED
) 2006-12-07
(at)pruemmer -- (NORMAL_TYPE
) 2006-12-07
(at)bweiss -- (NORMAL_TYPE
) 2006-12-11
(at)bweiss -- (NORMAL_TYPE
) 2006-12-11
(at)bweiss -- (NORMAL_TYPE
) 2006-12-11
(at)bweiss -- (NORMAL_TYPE
) 2006-12-11
(at)bweiss -- (BUGNOTE_ADDED
) 2006-12-11
(at)pruemmer -- (NORMAL_TYPE
) 2006-12-12
(at)pruemmer -- (NORMAL_TYPE
) 2006-12-12
(at)pruemmer -- (BUGNOTE_ADDED
) 2006-12-12
(at)bweiss -- (NORMAL_TYPE
) 2006-12-13
(at)bweiss -- (NORMAL_TYPE
) 2006-12-13
(at)bweiss -- (BUGNOTE_ADDED
) 2006-12-13
(at)pruemmer -- (NORMAL_TYPE
) 2006-12-17
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-930
Submitted on: 2008-12-09 by (at)most
Updated: 2012-03-09
Assigned to: (at)bweiss
Some unsupported JML features prevent problems from being loaded (either gracefully or less gracefully), while they can be simply ignored and warned about. Some examples:
- informal predicates (KeY exists with an appropriate message)
- (at)assume statements (KeY mumbles about ghost or model fields)
- (at)assert statements (similar)
- (at)nowarn pragmas (similar)
Probably more, these are only from the top of my head...
(at)bweiss at 2008-12-09
The error messages are better now for the cases you mentioned.
(at)bweiss at 2008-12-22
Graceful handling of unsupported JML features is implemented in 2bf9425. There may still be some features which the parser does not know about -- if you find any of these, feel free to reopen.
(at)most -- (NEW_BUG
) 2008-12-09
(at)bweiss -- (BUGNOTE_ADDED
) 2008-12-09
(at)bweiss -- (BUGNOTE_ADDED
) 2008-12-22
(at)bweiss -- (NORMAL_TYPE
) 2008-12-22
(at)bweiss -- (NORMAL_TYPE
) 2008-12-22
(at)bweiss -- (NORMAL_TYPE
) 2008-12-22
(at)most -- (NORMAL_TYPE
) 2012-03-09
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-71
Submitted on: 2002-10-02 by (at)giese
Updated: 2002-11-25
Assigned to: (at)aroth
Tryu parsing the problem:
<{int i;}> < { i=i+1; } > true
There is an error because the parser can't resolve the i in the second diamond.
(at)aroth at 2002-10-04
Fixed in 0.382.
Has already worked for interactive input but not for the problem files. Parser inheritance made it a bit invisible...
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-132
Submitted on: 2003-02-25 by (at)platzer
Updated: 2005-03-29
Assigned to: (at)klebanov
KeY-Installer
After having installed KeY from java -jar key.jar, starting Together with the KeY extension leads to
java.lang.RuntimeException: Couldn't find action id=_exit
at zanm.setCommand([DashoPro-V2-050200])
at com.togethersoft.together.impl.windowSystem.WindowManagerImpl.getAppl
icationFrame([DashoPro-V2-050200])
at com.togethersoft.together.impl.windowSystem.WindowManagerImpl.(
[DashoPro-V2-050200])
at zim.startup([DashoPro-V2-050200])
at com.togethersoft.together.impl.application.AddinLoaderImpl.startup([D
ashoPro-V2-050200])
at com.togethersoft.together.impl.application.ApplicationImpl.init([Dash
oPro-V2-050200])
at com.togethersoft.together.impl.application.ApplicationImpl.run([Dasho
Pro-V2-050200])
at com.togethersoft.together.Main.main([DashoPro-V2-050200])
[command_exception] java.lang.NullPointerException
[command_exception] at zaca.markState([DashoPro-V2-050200])
[command_exception] at zana.run([DashoPro-V2-050200])
[command_exception] java.lang.NullPointerException
[command_exception] at zbrw.performUpdate([DashoPro-V2-050200])
[command_exception] at zbrw.performUpdate([DashoPro-V2-050200])
[command_exception] at zana.run([DashoPro-V2-050200])
[command_exception] java.lang.NullPointerException
[command_exception] at zaca.markState([DashoPro-V2-050200])
[command_exception] at zana.run([DashoPro-V2-050200])
[command_exception] java.lang.NullPointerException
[command_exception] at zbrw.performUpdate([DashoPro-V2-050200])
[command_exception] at zbrw.performUpdate([DashoPro-V2-050200])
[command_exception] at zana.run([DashoPro-V2-050200])Possible reasons:
- KeY.jar installer should warn whenever there are spaces in any path (which may well happen under Windows) since otherwise the start
scripts generated won't work.
- Most possibly,
1 contained in paths like "F:\Progra1....." causes the problem, however, using "F:\Program Files......" instead, does notwork either. So neither spaces nor (under Windows) tildas should be allowed to occur.
- under Windows, the Key\bin\misc.config file has strange line feeds , and looks like
...^M
^Mdownload.help.url=http://www.togethersoft.com/downloads; some extensions for key-users
pattern.root.4 = "F:\Progra1\Sprachen\Together\key\keypatterns\de\uka\ilkd\key\casetool\together\patterns"1\Sprachen\Together\key\keyscripts")
scriptloader.root.6 = file("F:\Progra
scriptloader.root.6.name = "Key folder"Also, in the KeY-Installer tab Library, the "all" button does not truely work for entering the path. Also, the "Together\key\keyscripts" is due
to the "" at the end of the default Path inthe corresponding input field.
Also, KeY-Installer skips writing startKey.bat etc. when those files are already present, even if the settings have changed and it should berewritten.
Also startkey.bat often has wrong %JDK% or %JRE%.
Installing Together 6.0 and Key realls needs JVM 1.3 in almost every single step of the installation and run procedure. Seems the best is
not having a JVM 1.4 installed yet until everything runs. Neither Together 6.0 nor KeY work correctly with JVM 1.4
Reinstall KeY to different folders including different locations of Together. Some with and some without spaces and or tildas.
C:\Program Files\Together\KeY is no good idea.
C:\Progra~1\Together\KeY neither is.
C:\Together\KeY generally seems to work.
(at)platzer at 2003-03-03
This bug is irrelevant to us. But in case we ever expect to have a Windows KeY user, he will most possibly run into this problem. Since he does not get any comprehensible error messages from Windows/Together/KeY, he might end up experimenting half a week trying different combinations to get the whole thing up and running. This process certainly requires more patience than I would suspect the average expert Windows user to have.
Since noone ever read a FAQ, anyway, I suggest that emmitting explicit warning messages during installation is the preferred way of dealing with this problem. Except, perhaps, when someone expects bug submission at TogetherSoft or Microsoft to have an even higher impact.
(at)klebanov at 2004-06-16
André, would you please check if this problem persists with Together 6.2 and current KeY?
(at)klebanov at 2005-03-22
Looks like the problem has been solved. Please reopen if unsatisfied.
(at)platzer at 2005-03-29
unchecked
(at)klebanov -- (BUGNOTE_ADDED
) 2004-06-16
(at)klebanov -- (NORMAL_TYPE
) 2005-03-22
(at)klebanov -- (NORMAL_TYPE
) 2005-03-22
(at)klebanov -- (NORMAL_TYPE
) 2005-03-22
(at)klebanov -- (BUGNOTE_ADDED
) 2005-03-22
(at)platzer -- (NORMAL_TYPE
) 2005-03-29
(at)platzer -- (BUGNOTE_ADDED
) 2005-03-29
(at)grahl -- (NORMAL_TYPE
) 2015-09-28
Information:
This issue was created at git.key-project.org where the discussions are preserved.
If a taclet is introduced by another taclet during a proof (e.g., hide_left), the introduced taclet is named based on a global counter. The name is thus influenced by pruning the proof, order of rule application on different branches, etc. The name is not saved with the proof at the moment of introduction, thus later during loading the introduced taclet may not be available under the same name. It is a matter of pure luck that proofs using weakening (any serious proof) can be loaded at all.
A solution would be to save the introduced name with the proof and use it when the taclet is to be introduced in the proof instance that is being loaded.
(at)grahl at 2015-06-10
is this in the 2.4.1 release,too?
(at)klebanov -- (NEW_BUG
) 2015-05-17
(at)grahl -- (BUGNOTE_ADDED
) 2015-06-10
Information:
This issue was created at git.key-project.org where the discussions are preserved.
The \singleton operator can be called with an argument which is not a
location, like
//@ set l = \singleton(3);This does not raise a syntax error.
An ugly assertion error is thrown during the proof.
Load the attached A.java and auto-prove it. It will fail with an assertion failure:
java.lang.AssertionError: unexpected argument of \singleton: _g at de.uka.ilkd.key.java.TypeConverter.translateOperator(TypeConverter.java:159) at de.uka.ilkd.key.java.TypeConverter.convertToLogicElement(TypeConverter.java:385) at ...
There exists evidence that similar effects may appear for "assignable" clauses
A.java
:
class A {
//@ ghost \locset l;
//@ ensures true;
void m() {
//@ set l = \singleton(3);
{}
}
}
(at)mulbrich -- (NEW_BUG
) 2013-01-17
(at)mulbrich -- (FILE_ADDED
) 2013-01-17
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-968
Submitted on: 2009-12-11 by (at)rbubel
Updated: 2009-12-11
Assigned to: (at)gladisch
After running Simplify (unsuccessfully; cannot close a goal), the progress status bar starts flickering when restarting the normal strategies.
When running the test cases I get regularly (but not always) the following exception:
Original Error-Message: Stream closed
at de.uka.ilkd.key.smt.AbstractSMTSolver.run(AbstractSMTSolver.java:428)
at de.uka.ilkd.key.smt.AbstractSMTSolver.run(AbstractSMTSolver.java:199)
at de.uka.ilkd.key.smt.test.TestSMTSolver.checkFile(TestSMTSolver.java:201)
at de.uka.ilkd.key.smt.test.TestSMTSolver.correctResult(TestSMTSolver.java:170)
at de.uka.ilkd.key.smt.test.TestSMTSolver.testEqui2(TestSMTSolver.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at TestKey$1.run(TestKey.java:102)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.textui.TestRunner.doRun(TestRunner.java:116)
at junit.textui.TestRunner.start(TestRunner.java:172)
at junit.textui.TestRunner.main(TestRunner.java:138)
Caused by: java.io.IOException: Stream closed
at java.io.BufferedInputStream.getBufIfOpen(BufferedInputStream.java:145)
at java.io.BufferedInputStream.read(BufferedInputStream.java:308)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.read(BufferedReader.java:157)
at de.uka.ilkd.key.smt.AbstractSMTSolver.read(AbstractSMTSolver.java:175)
at de.uka.ilkd.key.smt.AbstractSMTSolver.run(AbstractSMTSolver.java:412)
... 24 more
(at)gladisch at 2009-12-11
I'm trying hard, with different (unprovable) examples, but I cannot reproduce the described problems. I also tried it with and without the SMT Progress Dialog -- no difference. Can you check if the bug is reproducible
(at)gladisch at 2009-12-11
Ok, the problem happens when the timeout of the Dec.Proc. is set sufficiently high. In my case it was only 3-4 seconds. I have reproduced the flickering with version e0030dc but in the latest version KeY freezes. It seems that a thread of the smt package is still running when the normal strategy is selectable.
I still can't reproduce the second problem. Some smt tests are performed but after the 5th dot "." (i.e.,[Testing integration of external SMT solvers]: .....) I get OutOfMemoryError (even if I change the JVM settings). Actually, on my computer the smt tests have never passed successfully yet, but I guess this is a different bug.
(at)gladisch at 2009-12-11
Fixed in version 3fe8752
(at)rbubel at 2009-12-11
Thanks a lot for the fix for 1)
I will have a look on 2) myself resp. will file it as a separate issue later.
(at)rbubel at 2009-12-11
Thanks a lot for the fix for 1)
I will have a look on 2) myself resp. will file it as a separate issue later.
(at)rbubel -- (NEW_BUG
) 2009-12-11
(at)gladisch -- (BUGNOTE_ADDED
) 2009-12-11
(at)gladisch -- (BUGNOTE_ADDED
) 2009-12-11
(at)gladisch -- (NORMAL_TYPE
) 2009-12-11
(at)gladisch -- (NORMAL_TYPE
) 2009-12-11
(at)gladisch -- (BUGNOTE_ADDED
) 2009-12-11
(at)gladisch -- (NORMAL_TYPE
) 2009-12-11
(at)gladisch -- (NORMAL_TYPE
) 2009-12-11
(at)gladisch -- (NORMAL_TYPE
) 2009-12-11
(at)rbubel -- (BUGNOTE_ADDED
) 2009-12-11
(at)rbubel -- (BUGNOTE_ADDED
) 2009-12-11
(at)rbubel -- (NORMAL_TYPE
) 2009-12-11
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-314
Submitted on: 2004-04-19 by (at)platzer
Updated: 2004-04-23
Assigned to: (at)rbubel
There is a NullPointerException bug, newly introduced between 0.994 and 0.1001.
See StR.
Loading the following file
---
java {
"/home/andre/personal/Text/Logic/proofExamples/src-da/"
}
include "standardRulesODL.key";
program variables {
C o;
C p;
}
problem {
<{ o.x = o.x + 1;
// C p = new C();
p.x = o.x + 2;
}> (p.x = +(o.x,2))
}
---
--- standardRulesODL.key ---
include "heuristicsDeclarations.key";
include LDTs:{"intRulesIgnoringOverflow.key", "booleanRules.key"};
//include LDTs:{"intRulesIgnoringOverflow.key", "intRules.key", "intRulesArith.key", "booleanRules.key"};
include "propRule.key";
include "odlRules.key";
include "genericRules.key";
---
leads to the following error with release 0.1001 but not with 0.994.
java.lang.NullPointerException
at de.uka.ilkd.key.parser.ProblemParser.attribute_suffix(ProblemParser.java:4369)
at de.uka.ilkd.key.parser.ProblemParser.accessterm(ProblemParser.java:3995)
at de.uka.ilkd.key.parser.ProblemParser.cond(ProblemParser.java:4347)
at de.uka.ilkd.key.parser.ProblemParser.term70(ProblemParser.java:4184)
at de.uka.ilkd.key.parser.ProblemParser.dlTermOrTerm70(ProblemParser.java:4042)
at de.uka.ilkd.key.parser.ProblemParser.term60(ProblemParser.java:2617)
at de.uka.ilkd.key.parser.ProblemParser.cond(ProblemParser.java:4236)
at de.uka.ilkd.key.parser.ProblemParser.term70(ProblemParser.java:4184)
at de.uka.ilkd.key.parser.ProblemParser.dlTermOrTerm70(ProblemParser.java:4042)
at de.uka.ilkd.key.parser.ProblemParser.term60(ProblemParser.java:2617)
at de.uka.ilkd.key.parser.ProblemParser.normal_dl_term(ProblemParser.java:4073)
at de.uka.ilkd.key.parser.ProblemParser.dlTermOrTerm70(ProblemParser.java:4018)
at de.uka.ilkd.key.parser.ProblemParser.term60(ProblemParser.java:2617)
at de.uka.ilkd.key.parser.ProblemParser.term50(ProblemParser.java:3877)
at de.uka.ilkd.key.parser.ProblemParser.term40(ProblemParser.java:3840)
at de.uka.ilkd.key.parser.ProblemParser.term30(ProblemParser.java:3804)
at de.uka.ilkd.key.parser.ProblemParser.term20(ProblemParser.java:3769)
at de.uka.ilkd.key.parser.ProblemParser.term(ProblemParser.java:1816)
at de.uka.ilkd.key.parser.ProblemParser.formula(ProblemParser.java:1188)
at de.uka.ilkd.key.parser.ProblemParser.problem(ProblemParser.java:739)
at de.uka.ilkd.key.proof.init.KeYUserProblemFile.read(KeYUserProblemFile.java:80)
at de.uka.ilkd.key.proof.init.ProblemInitializer.initializeProblem(ProblemInitializer.java:224)
at de.uka.ilkd.key.proof.init.ProblemInitializer.setUpProof(ProblemInitializer.java:252)
at de.uka.ilkd.key.proof.ProblemLoader.doWork(ProblemLoader.java:110)
at de.uka.ilkd.key.proof.ProblemLoader$1.construct(ProblemLoader.java:74)
at de.uka.ilkd.key.gui.SwingWorker$2.run(SwingWorker.java:116)
at java.lang.Thread.run(Thread.java:534)
(at)rbubel at 2004-04-19
fixed in v.1003
(at)most at 2004-04-23
Expressions like e.g. a1.a2[i].length give the same exception.
(at)rbubel at 2004-04-23
is not this bug, just a misleading error message in your case. see email
(at)most at 2004-04-23
OK, sorry!
(at)platzer -- (NEW_BUG
) 2004-04-19
(at)rbubel -- (BUGNOTE_ADDED
) 2004-04-19
(at)rbubel -- (NORMAL_TYPE
) 2004-04-19
(at)rbubel -- (NORMAL_TYPE
) 2004-04-19
(at)rbubel -- (NORMAL_TYPE
) 2004-04-19
(at)most -- (NORMAL_TYPE
) 2004-04-23
(at)most -- (NORMAL_TYPE
) 2004-04-23
(at)most -- (BUGNOTE_ADDED
) 2004-04-23
(at)rbubel -- (BUGNOTE_ADDED
) 2004-04-23
(at)rbubel -- (BUGNOTE_DELETED
) 2004-04-23
(at)rbubel -- (BUGNOTE_ADDED
) 2004-04-23
(at)rbubel -- (NORMAL_TYPE
) 2004-04-23
(at)rbubel -- (NORMAL_TYPE
) 2004-04-23
(at)most -- (NORMAL_TYPE
) 2004-04-23
(at)most -- (BUGNOTE_ADDED
) 2004-04-23
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-19
Submitted on: 2002-05-22 by (at)aroth
Updated: 2002-10-24
Assigned to: (at)klebanov
make on newly checked out version crashes with output as below. Version 0.314 still works.
Welcome.
ABSOLUTE PATHS required.
Please enter directory to place KeY configuration files in:
/amd.home/i11pc29/aroth/key/key315/cfg
[Create config files]
Identifier not defined
[Begin installation]
[Creating directory hierarchy]
[Copying config files]
mv: cannot statstartkey': No such file or directory chmod: getting attributes of
/amd.home/i11pc29/aroth/key/key315/cfg/bin/startkey': No such file or directory
mv: cannot statconfigDefaultSnapShot': No such file or directory cat: miscConfigExtension: No such file or directory [Installed] chmod: getting attributes of
runJava': No such file or directory
make: *** [config.mk] Error 1
prcs checkout -r0.315 key
cd system
make
<some path>
(at)klebanov at 2002-05-22
Used $@ in the runProver.template script confusing the keyword substitution.
Changed to $*. Should work now. Run `./runProver DEBUG' to get debug
output in standalone mode.
NORMAL_TYPE
) 2015-09-28Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-1278
Submitted on: 2013-02-21 by (at)scheben
Updated: 2013-03-18
Assigned to: (at)mulbrich
GUI freezes if close-button of dialogs is pressed
(at)mulbrich at 2013-02-21
very hot fix in cf41fd6684d5f995a2505cc7085ff0eb160c5dfd
The closing action on pressing the button has been deactivated
(at)scheben -- (NEW_BUG
) 2013-02-21
(at)mulbrich -- (NORMAL_TYPE
) 2013-02-21
(at)mulbrich -- (NORMAL_TYPE
) 2013-02-21
(at)mulbrich -- (NORMAL_TYPE
) 2013-02-21
(at)mulbrich -- (BUGNOTE_ADDED
) 2013-02-21
(at)mulbrich -- (NORMAL_TYPE
) 2013-02-21
(at)mulbrich -- (NORMAL_TYPE
) 2013-02-21
(at)grahl -- (NORMAL_TYPE
) 2013-03-18
(at)grahl -- (NORMAL_TYPE
) 2013-03-18
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-316
Submitted on: 2004-04-19 by (at)rbubel
Updated: 2004-04-30
Assigned to: (at)engelc
if calling getFullName on a class declaration one expects to get something like "java.lang.String" and not just "String" as it is returned at the moment.
(at)most at 2004-04-26
Now there is a new bug. getFullName for primitive array types returns
"noname" and should (probably) return the same as getName() in this case.
(at)most at 2004-04-28
Fixed that last thing in 1012, but it probably needs to reviewed.
(at)engelc at 2004-04-28
Fixed in 1022.
I removed the changes from 1021 because they are no longer necessary to fix the "noname"-problem (I hope).
(at)rbubel -- (NEW_BUG
) 2004-04-19
(at)rbubel -- (NORMAL_TYPE
) 2004-04-20
(at)engelc -- (NORMAL_TYPE
) 2004-04-23
(at)engelc -- (NORMAL_TYPE
) 2004-04-23
(at)most -- (BUGNOTE_ADDED
) 2004-04-26
(at)most -- (BUGNOTE_ADDED
) 2004-04-28
(at)engelc -- (NORMAL_TYPE
) 2004-04-28
(at)engelc -- (NORMAL_TYPE
) 2004-04-28
(at)engelc -- (BUGNOTE_ADDED
) 2004-04-28
(at)rbubel -- (NORMAL_TYPE
) 2004-04-30
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-786
Submitted on: 2007-02-17 by (at)pruemmer
Updated: 2007-02-19
Assigned to: (at)rbubel
According to the OCL standard, "implies" is the operator with the least precedence. The expression
x >= 0 implies x >= -1 and x >= -2
however, is wrongly parsed as
(x >= 0 implies x >= -1) and x >= -2
Also see the attached example
(at)rbubel at 2007-02-19
fixed in v0.2510
(at)pruemmer at 2007-02-19
Tusen tack!
(at)pruemmer -- (NEW_BUG
) 2007-02-17
(at)pruemmer -- (FILE_ADDED
) 2007-02-17
(at)rbubel -- (NORMAL_TYPE
) 2007-02-19
(at)rbubel -- (NORMAL_TYPE
) 2007-02-19
(at)rbubel -- (NORMAL_TYPE
) 2007-02-19
(at)rbubel -- (BUGNOTE_ADDED
) 2007-02-19
(at)pruemmer -- (NORMAL_TYPE
) 2007-02-19
(at)pruemmer -- (BUGNOTE_ADDED
) 2007-02-19
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-60
Submitted on: 2002-08-21 by (at)giese
Updated: 2011-02-15
Assigned to: (at)rbubel
Most of the concrete subclasses of ...logicdata.Op, i.e.
Junctor, Epsilon, SubstOp, MetaOp, etc. have
public constructors. They should be package private, so only the TermFactory can create Op objects.
(at)rbubel at 2003-07-31
fixed as far as possible in v.0.696
only the MetaOp are public as they are in another package rule/metaconstructs/arith, because they can just occur in rules
performed some other refactoring for operators and terms (term attribute sort is now final, therefore changed method sort(Term term) to sort(Term[] term) in interface operator
(at)giese at 2003-09-05
Someone did it again! WarySubstOp has a public constructor!
I propose writing a little module that uses reflection to check for public constructors when the system starts up...
(at)rbubel at 2003-09-05
- fixed in version 750
- added new kind of test called DesignTest. At the moment they check
Op constructors to be (package) private and subclasses of Term to be
(package) private. The latter test fails for Axiom at the moment.- Further tests can be added in a rather simple way.
(at)nanchen at 2003-10-03
The Op constructor have been made package private.
for asmkey, i need to derive a new class for the Junctor class to create a asmkey specific junctor.
i would need these Op constructors to be 'protected'.
(at)rbubel at 2003-10-06
For the first you can change the visibility of the operators on your side branch.
Before introducing these changes on the main branch, it may be helpful to know which kind of operator exactly (syntax and semantics) and why a subclass of junctor (what is the new required functionality)? Perhaps one can find a solution that keeps the package privacy.
(at)nanchen at 2004-06-15
I need to create new operators which are only used in ASMKeY: in particular, special short circuits boolean opertors and a 'timed' operator: I would like them to be junctors (to reuse your code).
I do not want to add asmkey code in the key part; so i need to access the constructor of Junctor in some way; i think a subclass of Junctor (when Junctor has a 'protected' constructor) is a possible solution. do you have any other ideas?
(at)rbubel at 2004-06-15
done in 0.1068
Btw. not sure if Junctor should be made abstract and then ASMKeY resp. KeY can have their own concrete subclasses...
(at)klebanov at 2006-07-04
Richard?
(at)rbubel at 2010-08-12
All Op subclasses have either protected or package private modfiers.
(at)bweiss at 2011-02-15
Closing as reporter is no longer available.
(at)rbubel -- (NORMAL_TYPE
) 2003-07-31
(at)rbubel -- (NORMAL_TYPE
) 2003-07-31
(at)rbubel -- (NORMAL_TYPE
) 2003-07-31
(at)rbubel -- (BUGNOTE_ADDED
) 2003-07-31
(at)giese -- (NORMAL_TYPE
) 2003-09-05
(at)giese -- (NORMAL_TYPE
) 2003-09-05
(at)giese -- (BUGNOTE_ADDED
) 2003-09-05
(at)rbubel -- (NORMAL_TYPE
) 2003-09-05
(at)rbubel -- (NORMAL_TYPE
) 2003-09-05
(at)rbubel -- (BUGNOTE_ADDED
) 2003-09-05
(at)nanchen -- (NORMAL_TYPE
) 2003-10-03
(at)nanchen -- (NORMAL_TYPE
) 2003-10-03
(at)nanchen -- (BUGNOTE_ADDED
) 2003-10-03
(at)rbubel -- (BUGNOTE_ADDED
) 2003-10-06
(at)nanchen -- (BUGNOTE_ADDED
) 2004-06-15
(at)nanchen -- (BUGNOTE_DELETED
) 2004-06-15
(at)nanchen -- (BUGNOTE_ADDED
) 2004-06-15
(at)rbubel -- (BUGNOTE_ADDED
) 2004-06-15
(at)klebanov -- (BUGNOTE_ADDED
) 2006-07-04
(at)rbubel -- (BUGNOTE_ADDED
) 2010-08-12
(at)rbubel -- (NORMAL_TYPE
) 2010-08-12
(at)rbubel -- (NORMAL_TYPE
) 2010-08-12
(at)bweiss -- (BUGNOTE_ADDED
) 2011-02-15
(at)bweiss -- (NORMAL_TYPE
) 2011-02-15
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-334
Submitted on: 2004-05-03 by (at)giese
Updated: 2004-08-24
Assigned to: (at)daniels
The taclet tool tips contain the complete instantiated taclet. I think the find(...) part is redundant, because that is what the user just clicked on. And the varcond(...) part is probably also superfluous, because the rule wouldn't be in the menu if the varcond weren't fulfilled (am I right?). For if(...) parts, I'm not sure, but it would probably be best to check whether the if-formulae are there: if yes don't mention them, if no, say that they will be added.
Let the tool tip say what will happen if I click here, not what were the preconditions that made it possible to click here.
(at)klebanov at 2004-05-03
I concur. The problem with if-formulae though is that you don't know WHICH one will be used... Or how did you envision this particular point?
(at)giese at 2004-05-03
You are right, vladimir. Maybe in the more complicated cases, one should just give the add/replacewith information and say that further interaction will be needed. That would have to be tried out.
(at)daniels at 2004-08-18
Since KeY 0.1202 find, varcond and heuristics of a Taclet aren't printed by default in the tooltip.
Can be switched on again under View->Taclet Options
(at)aroth at 2004-08-19
Just a small thing to make it perfect: Also the taclet name is redundant, since the mouse cursor already points to it in the taclet menu. Skipping name and first+last curly brace saves two further tooltip lines.
(at)daniels at 2004-08-23
In 0.1216 this was incorporated, the name and the braces won't get displayed if not switched on together with find & co.
(at)giese -- (NEW_BUG
) 2004-05-03
(at)klebanov -- (BUGNOTE_ADDED
) 2004-05-03
(at)giese -- (BUGNOTE_ADDED
) 2004-05-03
(at)daniels -- (NORMAL_TYPE
) 2004-06-01
(at)daniels -- (NORMAL_TYPE
) 2004-06-01
(at)daniels -- (NORMAL_TYPE
) 2004-08-18
(at)daniels -- (NORMAL_TYPE
) 2004-08-18
(at)daniels -- (BUGNOTE_ADDED
) 2004-08-18
(at)aroth -- (NORMAL_TYPE
) 2004-08-19
(at)aroth -- (NORMAL_TYPE
) 2004-08-19
(at)aroth -- (BUGNOTE_ADDED
) 2004-08-19
(at)daniels -- (NORMAL_TYPE
) 2004-08-23
(at)daniels -- (NORMAL_TYPE
) 2004-08-23
(at)daniels -- (BUGNOTE_ADDED
) 2004-08-23
(at)giese -- (NORMAL_TYPE
) 2004-08-24
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-566
Submitted on: 2005-06-28 by (at)most
Updated: 2005-07-04
Assigned to: (at)engelc
Method contracts generated from JML are not applicable on static method calls. Say you have a static method
staticMethod() in class MyClass with a JML specification, a contract taclet is properly generated, but it connot be applied on static call to MyClass.staticMethod().
Feed this example to KeY:
public class MyClass {
/*(at)
public normal_behavior
requires true;
ensures true;
assignable \nothing;
(at)*/
public void mainMethod() {
MyClass.staticMethod();
}
/*(at)
public normal_behavior
requires true;
ensures true;
assignable \nothing;
(at)*/
public static void staticMethod() {
}
}
Chrisitian, before you fix this bug, talk to Andreas as he is working (very hard I might add), on the contract things at the moment.
(at)engelc at 2005-07-04
fixed in 0.1691
(at)most at 2005-07-04
Indeed it works :)
(at)most -- (NEW_BUG
) 2005-06-28
(at)engelc -- (NORMAL_TYPE
) 2005-07-04
(at)engelc -- (NORMAL_TYPE
) 2005-07-04
(at)engelc -- (NORMAL_TYPE
) 2005-07-04
(at)engelc -- (NORMAL_TYPE
) 2005-07-04
(at)engelc -- (BUGNOTE_ADDED
) 2005-07-04
(at)most -- (NORMAL_TYPE
) 2005-07-04
(at)most -- (BUGNOTE_ADDED
) 2005-07-04
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-1224
Submitted on: 2012-10-08 by (at)grahl
Updated: 2013-03-18
Assigned to: (at)scheben
Tried with fdb7fb4cd6060b0673b0c13533988943e9b241e2
Looks as it had been introduced with block contracts.[creating JML pre parser]
ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
src/de/uka/ilkd/key/speclang/jml/pretranslation/jmlpreparser.g:197: warning:nondeterminism between alts 3 and 7 of block upon
src/de/uka/ilkd/key/speclang/jml/pretranslation/jmlpreparser.g:197: k==1:"assignable","assignable_redundantly","modifiable","modifiable_redundantly","modifies","modifies_redundantly"
[creating JML lexer]
ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
[creating JML parser]
ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
src/de/uka/ilkd/key/speclang/jml/translation/jmlparser.g:536:23: warning:nondeterminism between alts 1 and 2 of block upon
src/de/uka/ilkd/key/speclang/jml/translation/jmlparser.g:536:23: k==1:LPAREN
src/de/uka/ilkd/key/speclang/jml/translation/jmlparser.g:536:23: k==2:IDENT
src/de/uka/ilkd/key/speclang/jml/translation/jmlparser.g:550:29: warning:nondeterminism between alts 1 and 2 of block upon
src/de/uka/ilkd/key/speclang/jml/translation/jmlparser.g:550:29: k==1:LPAREN
src/de/uka/ilkd/key/speclang/jml/translation/jmlparser.g:550:29: k==2:IDENT
(at)scheben at 2012-10-19
fixed in commit 57c1dece4aa236d1a136723686c3c0f8fb3f4f20
(at)grahl -- (NEW_BUG
) 2012-10-08
(at)scheben -- (NORMAL_TYPE
) 2012-10-19
(at)scheben -- (NORMAL_TYPE
) 2012-10-19
(at)scheben -- (BUGNOTE_ADDED
) 2012-10-19
(at)scheben -- (NORMAL_TYPE
) 2012-10-19
(at)scheben -- (NORMAL_TYPE
) 2012-10-19
(at)grahl -- (NORMAL_TYPE
) 2013-03-18
(at)grahl -- (NORMAL_TYPE
) 2013-03-18
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-1008
Submitted on: 2010-07-26 by (at)gpaganelli
Updated: 2012-12-11
Assigned to: (at)rbubel
When using the symbolic debugger, interaction with the KeY prover should be restricted since pruning the proof tree leads to an inconsistent state the current symbolic debugging.
Load a java file into eclipse with a method M
Start symbolic debugging of M and execute to a certain point
Switch to the KeY main window
Prune the tree from the proof tree view
In the eclipse view the symbolic debugger won't work anymore
(at)rbubel at 2012-12-11
Symbolic Execution Debugger reimplemented by Martin. As this bug relates to the old one, I close this bug.
(at)gpaganelli -- (NEW_BUG
) 2010-07-26
(at)bweiss -- (NORMAL_TYPE
) 2010-09-27
(at)rbubel -- (BUGNOTE_ADDED
) 2012-12-11
(at)rbubel -- (NORMAL_TYPE
) 2012-12-11
(at)rbubel -- (NORMAL_TYPE
) 2012-12-11
(at)rbubel -- (NORMAL_TYPE
) 2012-12-11
(at)rbubel -- (NORMAL_TYPE
) 2012-12-11
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-736
Submitted on: 2006-11-07 by (at)pruemmer
Updated: 2006-11-08
Assigned to: (at)rbubel
At some point between 0.2388 and 0.2392, key has started to always (i.e., independently from the chosen integer semantics, I am using the mathematical/unbounded semantics) use operations like subJint when translating (in)variants given in JML. More precisely, in paycard.logfile.getMax... I get a variant subJint(a.length, i). At the same time, for this integer semantics it is not possible to expand subJint, which makes the problem unprovable.
(at)rbubel at 2006-11-07
fixed in 0.2394
(at)pruemmer at 2006-11-08
Tackar!
(at)pruemmer -- (NEW_BUG
) 2006-11-07
(at)rbubel -- (NORMAL_TYPE
) 2006-11-07
(at)rbubel -- (NORMAL_TYPE
) 2006-11-07
(at)rbubel -- (NORMAL_TYPE
) 2006-11-07
(at)rbubel -- (BUGNOTE_ADDED
) 2006-11-07
(at)pruemmer -- (NORMAL_TYPE
) 2006-11-08
(at)pruemmer -- (BUGNOTE_ADDED
) 2006-11-08
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-1176
Submitted on: 2012-04-23 by (at)mulbrich
Updated: 2012-04-24
Assigned to: (at)grahl
When I try to disable the usage of unicode symbols (? instead of \forall) in the View menu, the sequent view does not change and still shows the characters.
(at)grahl at 2012-04-24
In order to switch off Unicode, pretty printing has to be restarted. For the time, click twice on the PP button.
(at)grahl at 2012-04-24
notations were cached in a wrong way
(at)mulbrich at 2012-04-24
Thanks!
Apparently, the sequent view also no longer "scrolls away" after a rule application when using unicode. You fixed that bug, too, before I could even post it :-)
(at)mulbrich -- (NEW_BUG
) 2012-04-23
(at)grahl -- (NORMAL_TYPE
) 2012-04-24
(at)grahl -- (NORMAL_TYPE
) 2012-04-24
(at)grahl -- (BUGNOTE_ADDED
) 2012-04-24
(at)grahl -- (BUGNOTE_ADDED
) 2012-04-24
(at)grahl -- (NORMAL_TYPE
) 2012-04-24
(at)grahl -- (NORMAL_TYPE
) 2012-04-24
(at)mulbrich -- (BUGNOTE_ADDED
) 2012-04-24
(at)mulbrich -- (NORMAL_TYPE
) 2012-04-24
Information:
This issue was created at git.key-project.org where the discussions are preserved.
when arrays are involved the translation to simplify prints:
sort=java.lang.String, opName=array, opClass=de.uka.ilkd.key.logic.op.ArrayOp
Warning: unknown operator while translating into simplify syntax.
I will quit here.
(at)aroth at 2004-08-23
Actually it should be possible to translate arrays to Simplify. At least the page http://research.compaq.com/SRC/esc/simplify/Simplify.1.html claims that there are axioms for arrays built into Simplify. And also ESC/Java certainly relies on such a possibility.
(at)rbubel at 2006-07-04
seems to be fixed
(at)rbubel -- (NEW_BUG
) 2003-08-01
(at)aroth -- (BUGNOTE_ADDED
) 2004-08-23
(at)rbubel -- (NORMAL_TYPE
) 2006-07-04
(at)rbubel -- (BUGNOTE_ADDED
) 2006-07-04
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-1240
Submitted on: 2012-11-20 by (at)most
Updated: 2014-01-16
Assigned to: (at)mulbrich
Was thinking about writing an email first, but I sense this should be documented in bug tracker regardless of whether I am right or not.
(Also I am not working with the most recent master).
Well, to the point. The cut formula introduced by the application of the dependency contract contains the condition on the measured_by clause, i.e. that it should be strictly less than the mbyAtPre present in the proof. This makes sense when dep. contracts are applied in the PO that refer to the same contract, so that there is a progress/soundness in recursion (or so I believe without thinking too much). It does not make sense, in my opinion, to include this condition when one applies a dep. contract different than the current top level (dependency) contract. In particular the two measured_by clauses may have very little to do with each other, so one cannot require that the one from the contract being applied is decreased (w.r.t. what when measured_by-s are different).
I think this is related to the other bugs w.r.t. the represents/dependecy handling that were dealt with a short while back and also to the discussions we had with Mattias on the occasion of model methods.
(at)mulbrich at 2012-11-20
This issue with termination / wellfoundedness of model field definitions
has not yet been solved, I think.What about mutual recursion, like in:
class C {
int field;
//@ model int x; represents x = y;
//@ model int y; represents y = field;
//@ accessible x : \nothing \measured_by 0;
//@ accessible y : \nothing \measured_by 0;
}Without the requirement that the measured_by-clause is strictly decreasing,
x and y could give each other a false 'alibi'.But there must be a better approach to all this ... Let's find it :-)
EDIT: This is not even recursion, but simple dependence.
(at)most at 2012-11-20
Yes, let's! With the dep. contract application conditions relaxed (not to check mby unless circular application) life with KeY becomes much more bearable, and in case of my example (FM2012 problem 3) still sound I think (though my dependencies became a bit contrived, so I cannot be sure anymore :D).
(at)mulbrich at 2012-11-20
Second thought on recursion and variants:
Assume that variants could also be given as pairs of integers such that:
(a,b) < (c,d) :<=> ( 0 <= a < c | a=c & 0 < b < d )We could then make out "recursion groups", that is methods/model fields which
mutually refer to each other (in transitive closure). By definition, the call
graph between recursion groups is acyclic and we can assign to every group
a first coordinate such that calls only decrease the first component.By doing so, we can decouple "different" recursion from another or combine
recursive and non-recursive entities.
(at)most -- (NEW_BUG
) 2012-11-20
(at)mulbrich -- (BUGNOTE_ADDED
) 2012-11-20
(at)mulbrich -- (BUGNOTE_UPDATED
) 2012-11-20
(at)most -- (BUGNOTE_ADDED
) 2012-11-20
(at)mulbrich -- (BUGNOTE_ADDED
) 2012-11-20
(at)mulbrich -- (BUG_ADD_RELATIONSHIP
) 2012-11-22
(at)grahl -- (BUG_ADD_RELATIONSHIP
) 2013-11-25
(at)grahl -- (NORMAL_TYPE
) 2013-11-25
(at)grahl -- (NORMAL_TYPE
) 2013-11-25
(at)grahl -- (NORMAL_TYPE
) 2013-11-25
(at)grahl -- (NORMAL_TYPE
) 2013-11-25
(at)grahl -- (NORMAL_TYPE
) 2013-11-25
(at)grahl -- (NORMAL_TYPE
) 2014-01-16
Information:
This issue was created at git.key-project.org where the discussions are preserved.
The following exception is thrown by remove generics.
Caused by: java.lang.UnsupportedOperationException: TODO
at recoder.bytecode.ByteCodeParser.readFormalTypeParameters(ByteCodeParser.java:813)
at recoder.bytecode.ByteCodeParser.readMethodSignature(ByteCodeParser.java:1017)
at recoder.bytecode.ByteCodeParser.readAttributesForMethod(ByteCodeParser.java:394)
at recoder.bytecode.ByteCodeParser.readMethodInfo(ByteCodeParser.java:571)
at recoder.bytecode.ByteCodeParser.parseClassFile(ByteCodeParser.java:119)
at recoder.bytecode.ByteCodeParser.parseClassFile(ByteCodeParser.java:71)
at recoder.io.DefaultClassFileRepository.getClassFile(DefaultClassFileRepository.java:117)
at recoder.service.DefaultNameInfo.loadClassFromPrecompiledCode(DefaultNameInfo.java:631)
at recoder.service.DefaultNameInfo.loadClass(DefaultNameInfo.java:614)
at recoder.service.DefaultNameInfo.getType(DefaultNameInfo.java:492)
at recoder.service.DefaultNameInfo.getClassType(DefaultNameInfo.java:429)
at recoder.service.DefaultSourceInfo.getType(DefaultSourceInfo.java:826)
at recoder.service.DefaultCrossReferenceSourceInfo.analyzeReferences(DefaultCrossReferenceSourceInfo.java:460)
at recoder.service.DefaultCrossReferenceSourceInfo.analyzeReferences(DefaultCrossReferenceSourceInfo.java:430)
at recoder.service.DefaultCrossReferenceSourceInfo.analyzeReferences(DefaultCrossReferenceSourceInfo.java:430)
at recoder.service.DefaultCrossReferenceSourceInfo.modelChanged(DefaultCrossReferenceSourceInfo.java:222)
at recoder.service.ChangeHistory.updateModel(ChangeHistory.java:502)
at de.uka.ilkd.key.util.removegenerics.AbstractGenericRemover.removeGenerics(AbstractGenericRemover.java:65)
at org.key_project.removegenerics.ui.wizard.RemoveGenericsWizard.removeGeneris(RemoveGenericsWizard.java:166)
... 2 more
Root exception:
java.lang.UnsupportedOperationException: TODO
at recoder.bytecode.ByteCodeParser.readFormalTypeParameters(ByteCodeParser.java:813)
at recoder.bytecode.ByteCodeParser.readMethodSignature(ByteCodeParser.java:1017)
at recoder.bytecode.ByteCodeParser.readAttributesForMethod(ByteCodeParser.java:394)
at recoder.bytecode.ByteCodeParser.readMethodInfo(ByteCodeParser.java:571)
at recoder.bytecode.ByteCodeParser.parseClassFile(ByteCodeParser.java:119)
at recoder.bytecode.ByteCodeParser.parseClassFile(ByteCodeParser.java:71)
at recoder.io.DefaultClassFileRepository.getClassFile(DefaultClassFileRepository.java:117)
at recoder.service.DefaultNameInfo.loadClassFromPrecompiledCode(DefaultNameInfo.java:631)
at recoder.service.DefaultNameInfo.loadClass(DefaultNameInfo.java:614)
at recoder.service.DefaultNameInfo.getType(DefaultNameInfo.java:492)
at recoder.service.DefaultNameInfo.getClassType(DefaultNameInfo.java:429)
at recoder.service.DefaultSourceInfo.getType(DefaultSourceInfo.java:826)
at recoder.service.DefaultCrossReferenceSourceInfo.analyzeReferences(DefaultCrossReferenceSourceInfo.java:460)
at recoder.service.DefaultCrossReferenceSourceInfo.analyzeReferences(DefaultCrossReferenceSourceInfo.java:430)
at recoder.service.DefaultCrossReferenceSourceInfo.analyzeReferences(DefaultCrossReferenceSourceInfo.java:430)
at recoder.service.DefaultCrossReferenceSourceInfo.modelChanged(DefaultCrossReferenceSourceInfo.java:222)
at recoder.service.ChangeHistory.updateModel(ChangeHistory.java:502)
at de.uka.ilkd.key.util.removegenerics.AbstractGenericRemover.removeGenerics(AbstractGenericRemover.java:65)
at org.key_project.removegenerics.ui.wizard.RemoveGenericsWizard.removeGeneris(RemoveGenericsWizard.java:166)
at org.key_project.removegenerics.ui.wizard.RemoveGenericsWizard$2.run(RemoveGenericsWizard.java:98)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
1. Use Eclipse with Remove Generics installed.
2. Import the attached Java project.
3. Select context menu item 'Remove Generics' of the Java Project.
I set the priority to low, because a different example with a TODO works as it should.
(at)mulbrich at 2015-08-11
With which bytecode version of the class did this occur?
(at)mulbrich at 2015-08-11
I assume the method "concat" in MiscTool may be responsible for that:
public static <S,T extends S> S[] concat(S[] s1, T[] s2)
.method public static concat([Ljava/lang/Object;[Ljava/lang/Object;)[Ljava/lang/Object;
.signature "<S:Ljava/lang/Object;T:TS;>([TS;[TT;)[TS;""T extends S" seems to be the case that is tagged "TODO" in recoder.
I checked the current version of original recoder and this TODO is still there.
(at)mhentschel -- (NEW_BUG
) 2015-08-10
(at)mulbrich -- (BUGNOTE_ADDED
) 2015-08-11
(at)mulbrich -- (BUGNOTE_ADDED
) 2015-08-11
(at)grahl -- (TAG_ATTACHED
) 2015-08-18
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-755
Submitted on: 2007-01-08 by (at)most
Updated: 2008-03-03
Assigned to: (at)bweiss
Starting a proof for used specifications (DL contracts) crashes. The trace is included in Additional inforamtion. To reproduce try systemex6.key from the KeY book examples (chapter 9) - after the main proof try to start a proof for setAtoZero and presto.
java.lang.ArrayIndexOutOfBoundsException: 1
at de.uka.ilkd.key.logic.ArrayOfTerm.getTerm(ArrayOfTerm.java:46)
at de.uka.ilkd.key.logic.ProgramTerm.sub(ProgramTerm.java:58)
at de.uka.ilkd.key.proof.mgt.DLHoareTriplePO.desugar(DLHoareTriplePO.java:61)
at de.uka.ilkd.key.proof.mgt.DLHoareTriplePO.<init>(DLHoareTriplePO.java:42)
at de.uka.ilkd.key.proof.mgt.DLMethodContract.getProofOblInput(DLMethodContract.java:335)
at de.uka.ilkd.key.gui.UsedMethodContractsList.openNewProofForCurrentContract(UsedMethodContractsList.java:201)
at de.uka.ilkd.key.gui.UsedMethodContractsList$3$1.run(UsedMethodContractsList.java:123)
at de.uka.ilkd.key.gui.KeYMediator.invokeAndWait(KeYMediator.java:1002)
at de.uka.ilkd.key.gui.UsedMethodContractsList$3.actionPerformed(UsedMethodContractsList.java:126)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236)
at java.awt.Component.processMouseEvent(Component.java:5501)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)
at java.awt.Component.processEvent(Component.java:5266)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3968)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1778)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:153)
at java.awt.Dialog$1.run(Dialog.java:525)
at java.awt.Dialog$2.run(Dialog.java:553)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Dialog.show(Dialog.java:551)
at java.awt.Component.show(Component.java:1300)
at java.awt.Component.setVisible(Component.java:1253)
at de.uka.ilkd.key.gui.UsedMethodContractsList.setVisible(UsedMethodContractsList.java:175)
at de.uka.ilkd.key.gui.TaskTree$BasicTaskPopupMenu.actionPerformed(TaskTree.java:330)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1849)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2169)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:420)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:258)
at javax.swing.AbstractButton.doClick(AbstractButton.java:302)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1000)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1041)
at java.awt.Component.processMouseEvent(Component.java:5501)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3135)
at java.awt.Component.processEvent(Component.java:5266)
at java.awt.Container.processEvent(Container.java:1966)
at java.awt.Component.dispatchEventImpl(Component.java:3968)
at java.awt.Container.dispatchEventImpl(Container.java:2024)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3892)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
at java.awt.Container.dispatchEventImpl(Container.java:2010)
at java.awt.Window.dispatchEventImpl(Window.java:1778)
at java.awt.Component.dispatchEvent(Component.java:3803)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
(at)bweiss at 2007-01-08
Like bugs #631, #702 and #718, this should disappear in the course of the ongoing contract mechanism refactoring (which will still take a rather long time though).
(at)most at 2007-01-08
I was suspecting so, I just did not want this to be forgotten ;)
(at)most at 2007-02-28
I change the title of the bug, I discovered what is the underlying problem: a DL contract cannot have a trivial precondition "true" - generating a proof for such a contract fails with the exception given before.
(at)bweiss at 2008-01-15
Fixed in 6684638.
(at)most -- (NEW_BUG
) 2007-01-08
(at)bweiss -- (NORMAL_TYPE
) 2007-01-08
(at)bweiss -- (NORMAL_TYPE
) 2007-01-08
(at)bweiss -- (BUGNOTE_ADDED
) 2007-01-08
(at)most -- (BUGNOTE_ADDED
) 2007-01-08
(at)most -- (BUGNOTE_ADDED
) 2007-02-28
(at)most -- (NORMAL_TYPE
) 2007-02-28
(at)bweiss -- (NORMAL_TYPE
) 2008-01-15
(at)bweiss -- (NORMAL_TYPE
) 2008-01-15
(at)bweiss -- (BUGNOTE_ADDED
) 2008-01-15
(at)most -- (NORMAL_TYPE
) 2008-03-03
Information:
This issue was created at git.key-project.org where the discussions are preserved.
Mantis: MT-236
Submitted on: 2003-10-17 by (at)angelaw
Updated: 2011-02-15
Assigned to: (at)most
Not possible to parse the "implicit attributes" which
appear after object creation. Complaints that "<"
is not expected.
(1) Proof attempt of program with some object creation
(I used an array).
(2) Apply heuristics.
(3) Pick induction rule (int_induction). Drag and drop the
pgm so it becomes most of the induction hypothesis.
This now includes "implicit attributes" from (2).
(4) Apply and parsing fails!
When reporting this bug:
1. I missed a category for "parsing".
2. This is a major problem for anybody attemting at
induction proofs for pgms t.contain objects. It might
be possible to overcome temporarily for some cases by
applying induction first and then heuristics.
(at)rbubel at 2003-11-03
in version 0.812 the implicit attributes are parsed when they occur in terms
not in the program (latter one is work in progress)
(at)rbubel at 2004-01-21
version 0.871:
The implicit fields and methods are now part of the recoder model as far as only objects are affected (arrays is another thing). Parsing for them should work now.
(at)most at 2005-05-31
That should be fixed for long time now.
(at)bweiss at 2011-02-15
Closing as reporter is no longer available.
(at)angelaw -- (NEW_BUG
) 2003-10-17
(at)rbubel -- (BUGNOTE_ADDED
) 2003-11-03
(at)rbubel -- (BUG_MONITOR
) 2003-11-03
(at)rbubel -- (NORMAL_TYPE
) 2003-11-15
(at)klebanov -- (NORMAL_TYPE
) 2003-12-17
(at)klebanov -- (NORMAL_TYPE
) 2003-12-17
(at)rbubel -- (BUGNOTE_ADDED
) 2004-01-21
(at)most -- (NORMAL_TYPE
) 2005-05-31
(at)most -- (NORMAL_TYPE
) 2005-05-31
(at)most -- (NORMAL_TYPE
) 2005-05-31
(at)most -- (BUGNOTE_ADDED
) 2005-05-31
(at)bweiss -- (BUGNOTE_ADDED
) 2011-02-15
(at)bweiss -- (NORMAL_TYPE
) 2011-02-15
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
(at)grahl -- (NORMAL_TYPE
) 2014-01-03
Information:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.