keyproject / key Goto Github PK

KeY Theorem Prover for Deductive Java Verification

License: Other

Java 97.82% HTML 1.20% ANTLR 0.28% SMT 0.15% Shell 0.14% C 0.01% Dafny 0.01% TeX 0.02% PHP 0.01% CSS 0.02% Perl 0.15% Makefile 0.09% Scilab 0.01% Python 0.03% Gnuplot 0.01% StringTemplate 0.04% Smalltalk 0.02%

key formal-verification smt-solver static-analysis

key's Introduction

KeY -- Deductive Java Program Verifier

This repository is the home of the interactive theorem prover KeY for formal verification and analysis of Java programs. KeY comes as a standalone GUI application, which allows you to verify the functional correctness of Java programs with respect to formal specifications formulated in the Java Modeling Language JML. Moreover, KeY can also be used as a library e.g. for symbolic program execution, first order reasoning, or test case generation.

For more information, refer to

The current version of KeY is 2.12.2, licensed under GPL v2.

Feel free to use the project templates to get started using KeY:

Requirements

Hardware: >=2 GB RAM
Operating System: Linux/Unix, MacOSX, Windows
Java 17 or newer
Optionally, KeY can make use of the following binaries:
- SMT Solvers:
  - Z3
  - cvc5
  - CVC4
  - Princess

Content of the KeY folder

This folder provides a gradle-managed project following Maven's standard folder layout. There are several subprojects in this folder. In general, every key.*/ subproject contains a core component of KeY. Additional and optional components are in keyext.*/ folders. The file build.gradle is the root build script describing the dependencies and common build tasks for all subprojects.

key.util, key.core and key.ui are the base for the product "KeY Prover". Special care is needed if you plan to make changes here.

Compile and Run KeY

Assuming you are in the directory of this README file, you can create a runnable and deployable version with one of these commands:

With ./gradlew key.ui:run you can run the user interface of KeY directly from the repository. Use ./gradlew key.ui:run --args='--experimental' to enable experimental features.
Use ./gradlew classes to compile KeY, which includes running JavaCC and Antlr. Likewise, use ./gradlew testClasses if you also want to compile the JUnit test classes.
Test your installation with ./gradlew test. Be aware that this will usually take multiple hours to complete. With ./gradlew testFast, you can run a more lightweight test suite that should complete in a few minutes.

You can select a specific test case with the --tests argument. Wildcards are allowed.
```
./gradlew :key.<subproject>:test --tests "<class>.<method>"
```
You can debug KeY by adding the --debug-jvm option, then attaching a debugger at localhost:5005.
You can create a single jar-version, aka fat jar, of KeY with
```
./gradlew :key.ui:shadowJar
```
The file is generated in key.ui/build/libs/key-*-exe.jar.
A distribution is build with
```
./gradlew :key.ui:installDist :key.ui:distZip
```
The distribution can be tested by calling key.ui/install/key/bin/key.ui and is zipped in key.ui/build/distributions.

The distribution gives you potential of using single jar files.

Developing KeY

Quality is automatically assessed using SonarQube on each pull request. The results of the assessments (pass/fail) can be inspected in the checks section of the PR.

The rules and quality gate are maintained by Alexander Weigl [email protected] currently.
More guideline and documentation for the KeY development can be found under key-docs.

Issues and Bug Reports

For bug reports, please use the issue tracker or send a mail to [email protected].
For discussions, you may want to subscribe and use the mailing list [email protected] or use GitHub discussions.

Contributing to KeY

Feel free to submit pull requests via GitHub. Pull requests are assessed using automatic tests, formatting and static source checkers, as well as a manual review by one of the developers. More guidelines and documentation for the KeY development can be found under key-docs.

License Remark

This is the KeY project - Integrated Deductive Software Design
Copyright (C) 2001-2011 Universität Karlsruhe, Germany
						Universität Koblenz-Landau, Germany
						and Chalmers University of Technology, Sweden
Copyright (C) 2011-2024 Karlsruhe Institute of Technology, Germany
						Technical University Darmstadt, Germany
						Chalmers University of Technology, Sweden

The KeY system is protected by the GNU General Public License.
See LICENSE.TXT for details.

key's People

Contributors

Stargazers

Watchers

key's Issues

<deleted>

Op Constructors too public

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

Description

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.

Files

Notes

(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.

History

(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

Attributes

Category: Prover Core
Status: CLOSED
Severity: TWEAK
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.361
Tags []
Labels: ~Prover Core ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:50.736Z
updated_at: 2017-05-29T02:26:51.714Z
closed_at: 2017-05-29T02:26:51.634Z (closed_by: )
milestone:
user_notes_count: 0

Installation fails

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

Description

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 stat startkey': 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 stat configDefaultSnapShot': 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

Steps to reproduce

prcs checkout -r0.315 key
cd system
make
<some path>

Files

Notes

(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.

History

(at)grahl -- (NORMAL_TYPE) 2015-09-28

Attributes

Category: Deployment
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.315
Tags []
Labels: ~Deployment ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:54.165Z
updated_at: 2017-05-29T02:26:55.108Z
closed_at: 2017-05-29T02:26:54.952Z (closed_by: )
milestone:
user_notes_count: 0

GUI freezes if close-button of dialogs is pressed

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

Description

GUI freezes if close-button of dialogs is pressed

Files

Notes

(at)mulbrich at 2013-02-21

very hot fix in cf41fd6684d5f995a2505cc7085ff0eb160c5dfd

The closing action on pressing the button has been deactivated

History

(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

Attributes

Category: GUI
Status: CLOSED
Severity: MINOR
OS:
Target Version: 2.0
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: cf41fd6684d5f995a2505cc7085ff0eb160c5dfd
Build:
Tags []
Labels: ~GUI ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:11.214Z
updated_at: 2017-05-29T02:27:12.404Z
closed_at: 2017-05-29T02:27:12.302Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Pruning confuses symbolic debugger

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

Description

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.

Steps to reproduce

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

Files

Notes

(at)rbubel at 2012-12-11

Symbolic Execution Debugger reimplemented by Martin. As this bug relates to the old one, I close this bug.

History

(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

Attributes

Category: Symb. Debugger
Status: CLOSED
Severity: BLOCK
OS:
Target Version:
Resolution: WONT_FIX
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build:
Tags []
Labels: ~Symb. Debugger ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:56.021Z
updated_at: 2017-05-29T02:26:56.741Z
closed_at: 2017-05-29T02:26:56.643Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Singleton constructors may be using with non-locations yielding assertion failures

This issue was created at git.key-project.org where the discussions are preserved.

Mantis: MT-1263
Submitted on: 2013-01-17 by (at)mulbrich
Updated: 2013-01-17

Description

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.

Steps to reproduce

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 ...

Additional Information

There exists evidence that similar effects may appear for "assignable" clauses

Files

A.java:

class A {
   //@ ghost \locset l;
   
   //@ ensures true;
   void m() {
     //@ set l = \singleton(3);
     {}
   }
}

History

(at)mulbrich -- (NEW_BUG) 2013-01-17
(at)mulbrich -- (FILE_ADDED) 2013-01-17
(at)grahl -- (NORMAL_TYPE) 2014-01-03

Attributes

Category: JML (semantics)
Status: NEW
Severity: TWEAK
OS:
Target Version:
Resolution: OPEN
Priority: LOW
Reproducibility: HAVENOTTRIED
Platform:
Commit: 8fb64cf80e6d484df2e3bfdcb61f0cc41a1c287c
Build:
Tags []
Labels: ~JML (Semantics) ~LOW

View in Mantis

Information:

created_at: 2017-05-29T02:27:06.042Z
updated_at: 2021-06-22T12:00:52.086Z
closed_at: 2021-06-22T12:00:51.660Z (closed_by: weigl)
milestone:
user_notes_count: 3

Abfrage 'Exit: Are you sure?' spinnt

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

Description

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.

Files

Notes

(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

Attributes

Category: GUI
Status: CLOSED
Severity: MINOR
OS: 0.314
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build:
Tags []
Labels: ~GUI ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:14.476Z
updated_at: 2017-05-29T02:26:15.313Z
closed_at: 2017-05-29T02:26:15.207Z (closed_by: )
milestone:
user_notes_count: 0

OCL parser parses with wrong precedence

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

Description

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

Files

0786-tmp18.tar.gz

Notes

(at)rbubel at 2007-02-19

fixed in v0.2510

(at)pruemmer at 2007-02-19

Tusen tack!

History

(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

Attributes

Category: None
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: HIGH
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.2506
Tags []
Labels: ~Bug ~HIGH

View in Mantis

Information:

created_at: 2017-05-29T02:27:19.591Z
updated_at: 2017-05-29T02:27:21.504Z
closed_at: 2017-05-29T02:27:21.435Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Recoder can not parse the byte code of 'de.uka.ilkd.key.util.MiscTools'

This issue was created at git.key-project.org where the discussions are preserved.

Mantis: MT-1563
Submitted on: 2015-08-10 by (at)mhentschel
Updated: 2015-08-18

Description

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)

Steps to reproduce

1. Use Eclipse with Remove Generics installed.
2. Import the attached Java project.
3. Select context menu item 'Remove Generics' of the Java Project.

Additional Information

I set the priority to low, because a different example with a TODO works as it should.

Files

Notes

(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.

History

(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

Attributes

Category: Parser
Status: NEW
Severity: MINOR
OS:
Target Version:
Resolution: OPEN
Priority: LOW
Reproducibility: ALWAYS
Platform:
Commit: d1e9bf3ee09fe1751efca74e2be8de1ddbfe920f
Build:
Tags [{'name': 'recoder bug'}]
Labels: ~KeY Parser ~Bug ~LOW

View in Mantis

Information:

created_at: 2017-05-29T02:27:26.497Z
updated_at: 2017-05-29T02:27:27.289Z
closed_at: None (closed_by: )
milestone:
user_notes_count: 0

Unicode symbols cannot be deactivated

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

Description

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.

Files

Notes

(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 :-)

History

(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

Attributes

Category: GUI
Status: CLOSED
Severity: TWEAK
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build:
Tags []
Labels: ~GUI ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:38.289Z
updated_at: 2017-05-29T02:27:42.584Z
closed_at: 2017-05-29T02:27:39.122Z (closed_by: )
milestone:
user_notes_count: 0

Nondeterminism in JML parser

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

Description

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

Files

Notes

(at)scheben at 2012-10-19

fixed in commit 57c1dece4aa236d1a136723686c3c0f8fb3f4f20

History

(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

Attributes

Category: JML (semantics)
Status: CLOSED
Severity: MINOR
OS:
Target Version: 2.0
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit:
Build:
Tags []
Labels: ~JML (Semantics) ~Bug ~NORMAL
Version: 2.0 fixed in 2.0

View in Mantis

Information:

created_at: 2017-05-29T02:27:16.402Z
updated_at: 2017-05-29T02:27:17.241Z
closed_at: 2017-05-29T02:27:17.168Z (closed_by: )
milestone:
user_notes_count: 0

Non-trivial diverges clauses make you prove things twice.

This issue was created at git.key-project.org where the discussions are preserved.

Mantis: MT-1499
Submitted on: 2014-10-28 by (at)mulbrich
Updated: 2014-10-29

Description

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.

Steps to reproduce

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

Files

Notes

(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).

History

(at)mulbrich -- (NEW_BUG) 2014-10-28
(at)grahl -- (BUGNOTE_ADDED) 2014-10-29
(at)grahl -- (BUGNOTE_UPDATED) 2014-10-29

Attributes

Category: JML (semantics)
Status: NEW
Severity: MINOR
OS:
Target Version:
Resolution: OPEN
Priority: LOW
Reproducibility: HAVENOTTRIED
Platform:
Commit: 56061ba8f523ccb3a8d58d92447c4bad60b7c372
Build:
Tags []
Labels: ~JML (Semantics) ~Bug ~LOW

View in Mantis

Information:

created_at: 2017-05-29T02:26:22.421Z
updated_at: 2021-11-07T13:41:41.579Z
closed_at: None (closed_by: )
milestone:
user_notes_count: 0

getFullName of TypeDeclaration is wrong

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

Description

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.

Files

Notes

(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).

History

(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

Attributes

Category: Parser
Status: CLOSED
Severity: MAJOR
OS: 2.4.x
Target Version:
Resolution: FIXED
Priority: HIGH
Reproducibility: ALWAYS
Platform: x86
Commit: None
Build: 0.1004
Tags []
Labels: ~KeY Parser ~Bug ~HIGH

View in Mantis

Information:

created_at: 2017-05-29T02:27:22.482Z
updated_at: 2017-05-29T02:27:23.436Z
closed_at: 2017-05-29T02:27:23.267Z (closed_by: )
milestone:
user_notes_count: 0

DL contract cannot have a trivial precondition -> generation of associated proof fails

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

Description

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.

Additional Information

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)

Files

Notes

(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.

History

(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

Attributes

Category: Prover Core
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.2420
Tags []
Labels: ~Prover Core ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:44.840Z
updated_at: 2017-05-29T02:26:47.510Z
closed_at: 2017-05-29T02:26:47.443Z (closed_by: )
milestone:
user_notes_count: 0

Chaotic behaviour of Together - KeY interplay in some installation cases

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

Description

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:\Progra~~1....." causes the problem, however, using "F:\Program Files......" instead, does not

work 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"
scriptloader.root.6 = file("F:\Progra1\Sprachen\Together\key\keyscripts")
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 be

rewritten.

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

Steps to reproduce

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.

Files

Notes

(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

History

(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

Attributes

Category: Deployment
Status: CLOSED
Severity: MAJOR
OS: 2000
Target Version:
Resolution: UNABLE_TO_DUPLICATE
Priority: NORMAL
Reproducibility: RANDOM
Platform: Windows
Commit: None
Build: 0.497
Tags []
Labels: ~Deployment ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:13.687Z
updated_at: 2017-05-29T02:27:14.982Z
closed_at: 2017-05-29T02:27:14.757Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Parsing "implicit attributes" in induction rul application

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

Description

Not possible to parse the "implicit attributes" which
appear after object creation. Complaints that "<"
is not expected.

Steps to reproduce

(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!

Additional Information

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.

Files

Notes

(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.

History

(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

Attributes

Category: Parser
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: HIGH
Reproducibility: ALWAYS
Platform: Reiner's PC in Gbg
Commit: None
Build: key-0.788
Tags []
Labels: ~KeY Parser ~Bug ~HIGH

View in Mantis

Information:

created_at: 2017-05-29T02:26:57.578Z
updated_at: 2017-05-29T02:26:58.712Z
closed_at: 2017-05-29T02:26:58.609Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Proofs using taclet introduction (e.g., weakening rules) cannot be loaded

This issue was created at git.key-project.org where the discussions are preserved.

Mantis: MT-1543
Submitted on: 2015-05-17 by (at)klebanov
Updated: 2015-06-10

Description

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.

Files

Notes

(at)grahl at 2015-06-10

is this in the 2.4.1 release,too?

History

(at)klebanov -- (NEW_BUG) 2015-05-17
(at)grahl -- (BUGNOTE_ADDED) 2015-06-10

Attributes

Category: Proof Loading/Saving
Status: NEW
Severity: MAJOR
OS:
Target Version:
Resolution: OPEN
Priority: HIGH
Reproducibility: SOMETIMES
Platform:
Commit: c2f138489e0860de48c0887885f03b7bbe448b6e
Build:
Tags []
Labels: ~Proof Loading/Saving ~Bug ~HIGH

View in Mantis

Information:

created_at: 2017-05-29T02:26:59.780Z
updated_at: 2021-10-15T13:04:50.996Z
closed_at: None (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Tool Tips show redundant 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

Description

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.

Files

Notes

(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.

History

(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

Attributes

Category: GUI
Status: CLOSED
Severity: MINOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.1032
Tags []
Labels: ~GUI ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:33.466Z
updated_at: 2017-05-29T02:27:35.198Z
closed_at: 2017-05-29T02:27:35.128Z (closed_by: )
milestone:
user_notes_count: 0

ESCSimplify does not know how to handle arrays

This issue was created at git.key-project.org where the discussions are preserved.

Mantis: MT-222
Submitted on: 2003-08-01 by (at)rbubel
Updated: 2006-07-04

Description

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.

Files

Notes

(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

History

(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

Attributes

Category: Prover Core
Status: CLOSED
Severity: MINOR
OS: 2.4.x
Target Version:
Resolution: OPEN
Priority: NORMAL
Reproducibility: ALWAYS
Platform: x86
Commit: None
Build:
Tags []
Labels: ~Prover Core ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:16.196Z
updated_at: 2017-05-29T02:26:17.250Z
closed_at: 2017-05-29T02:26:17.058Z (closed_by: )
milestone:
user_notes_count: 0

Translation of JML variants to DL always uses javaSemantics-arithmetic operations

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

Description

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.

Files

Notes

(at)rbubel at 2006-11-07

fixed in 0.2394

(at)pruemmer at 2006-11-08

Tackar!

History

(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

Attributes

Category: JML (semantics)
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.2392
Tags []
Labels: ~JML (Semantics) ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:24.511Z
updated_at: 2021-12-15T12:12:52.215Z
closed_at: 2017-05-29T02:27:25.116Z (closed_by: )
milestone:
user_notes_count: 0

Method contracts generated from JML are not applicable on static method calls

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

Description

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().

Steps to reproduce

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() {
  }
}

Additional Information

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.

Files

Notes

(at)engelc at 2005-07-04

fixed in 0.1691

(at)most at 2005-07-04

Indeed it works :)

History

(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

Attributes

Category: JML (semantics)
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: HIGH
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.1682
Tags []
Labels: ~JML (Semantics) ~Bug ~HIGH

View in Mantis

Information:

created_at: 2017-05-29T02:26:23.761Z
updated_at: 2017-05-29T02:26:38.873Z
closed_at: 2017-05-29T02:26:27.328Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

declared variables not visible to parser behind diamond

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

Description

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.

Files

Notes

(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...

Attributes

Category: Prover Core
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.380
Tags []
Labels: ~Prover Core ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:43.261Z
updated_at: 2017-05-29T02:27:43.714Z
closed_at: 2017-05-29T02:27:43.671Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Accelerator Key for Reload not working

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

Description

Hitting CTRL+w, CTRL+q, CTRL+o and CTRL+e works, but CTRL+r does nothing for me

Steps to reproduce

Start KeY, hit CTRL+r

Files

Notes

(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

History

(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

Attributes

Category: GUI
Status: CLOSED
Severity: MINOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform: i686
Commit: None
Build: 1.5.1541
Tags []
Labels: ~GUI ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:00.959Z
updated_at: 2017-05-29T02:27:01.998Z
closed_at: 2017-05-29T02:27:01.867Z (closed_by: )
milestone:
user_notes_count: 0

<deleted>

Dependency Contracts too strong?

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

Description

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.

Files

Notes

(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.

Associated Bugs

Relates to MT-1147 with

History

(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

Attributes

Category: Prover Core
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform:
Commit: 5d7771ead9c190e0e27a1e94bc00832c43e61486
Build:
Tags []
Labels: ~Prover Core ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:48.676Z
updated_at: 2017-05-29T02:39:04.374Z
closed_at: 2017-05-29T02:26:49.701Z (closed_by: )
milestone:
user_notes_count: 0

Unsupported JML features should not prevent loading the problem

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

Description

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...

Files

Notes

(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.

History

(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

Attributes

Category: JML (semantics)
Status: CLOSED
Severity: FEATURE
OS:
Target Version:
Resolution: FIXED
Priority: HIGH
Reproducibility: ALWAYS
Platform:
Commit: None
Build:
Tags []
Labels: ~JML (Semantics) ~Feature ~HIGH

View in Mantis

Information:

created_at: 2017-05-29T02:26:21.158Z
updated_at: 2017-05-29T02:26:21.801Z
closed_at: 2017-05-29T02:26:21.739Z (closed_by: )
milestone:
user_notes_count: 0

KeY / Recoder transforms JML set statments for ghost variables wrongly

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:

created_at: 2017-05-23T12:17:34.829Z
updated_at: 2021-09-15T20:27:13.010Z
closed_at: 2021-09-15T20:27:13.009Z (closed_by: weigl)
milestone:
user_notes_count: 4

<deleted>

Newly introduced attribute suffix NullPointer

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

Description

There is a NullPointerException bug, newly introduced between 0.994 and 0.1001.
See StR.

Steps to reproduce

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)

Files

Notes

(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!

History

(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

Attributes

Category: Parser
Status: CLOSED
Severity: MINOR
OS: 2.6.4 on 9.0
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: ALWAYS
Platform: Suse
Commit: None
Build: 0.1001
Tags []
Labels: ~KeY Parser ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:26:18.618Z
updated_at: 2017-05-29T02:26:19.553Z
closed_at: 2017-05-29T02:26:19.381Z (closed_by: )
milestone:
user_notes_count: 0

Race conditions in SMT

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

Description

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

Files

Notes

(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

before the SMT Progress Dialog
4593a8a

before restricting the application of DecProgRunner to the current node
e0030dc

(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.

History

(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

Attributes

Category: SMT
Status: CLOSED
Severity: MAJOR
OS:
Target Version:
Resolution: FIXED
Priority: NORMAL
Reproducibility: RANDOM
Platform:
Commit: None
Build:
Tags []
Labels: ~SMT ~Bug ~NORMAL

View in Mantis

Information:

created_at: 2017-05-29T02:27:36.595Z
updated_at: 2017-05-29T02:27:37.382Z
closed_at: 2017-05-29T02:27:37.334Z (closed_by: )
milestone:
user_notes_count: 0

@pre-functions in DL method contracts are not in namespace

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

Description

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.

Files

Notes

(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.

History

(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

Attributes

Category: GUI
Status: CLOSED
Severity: MINOR
OS:
Target Version:
Resolution: FIXED
Priority: URGENT
Reproducibility: ALWAYS
Platform:
Commit: None
Build: 0.2375
Tags []
Labels: ~GUI ~Bug ~URGENT

View in Mantis

Information:

created_at: 2017-05-29T02:25:56.869Z
updated_at: 2017-05-29T02:25:57.922Z
closed_at: 2017-05-29T02:25:57.828Z (closed_by: )
milestone:
user_notes_count: 0

keyproject / key Goto Github PK

key's Introduction

KeY -- Deductive Java Program Verifier

Requirements

Content of the KeY folder

Compile and Run KeY

Developing KeY

Issues and Bug Reports

Contributing to KeY

License Remark

key's People

Contributors

Stargazers

Watchers

Forkers

key's Issues

Description

Files

Notes

History

Attributes

Description

Steps to reproduce

Files

Notes

History

Attributes

Description

Files

Notes

History

Attributes

Description

Steps to reproduce

Files

Notes

History

Attributes

Description

Steps to reproduce

Additional Information

Files

History

Attributes

Description

Files

Notes

Attributes

Description

Files

Notes

History

Attributes

Description

Steps to reproduce

Additional Information

Files

Notes

History

Attributes

Description

Files

Notes

History

Attributes

Description

Files

Notes

History

Attributes

Description

Steps to reproduce

Files

Notes

History

Attributes

Description

Files

Notes

History

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.