New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Debug java project does not work properly #344

Closed
Debashis9012 opened this Issue Jan 17, 2019 · 1 comment

Comments

2 participants
@Debashis9012
Copy link
Contributor

Debashis9012 commented Jan 17, 2019

Expected behavior
Should be able to debug a java project

Actual behavior
Debug process is not happening correctly.
While debugging control moves to "Method.class" file

Steps to replicate

Observed on Windows

  • Download latest nightly vs code plugin and
    install it
  • Create a new java project
  • Navigate to created java project and keep
    debug point in implementation file.

Start debugging

Version

Gauge version: 1.0.4.nightly-2019-01-09
Commit Hash: 33123a1

Plugins
-------
html-report (4.0.7.nightly-2019-01-11)
java (0.7.0.nightly-2019-01-14)
js (2.3.4.nightly-2019-01-15)
screenshot (0.0.1)

IDE Version - gauge-0.0.8.nightly-2019-01-16

@BugDiver

This comment has been minimized.

Copy link
Member

BugDiver commented Jan 22, 2019

This has been seen only on the Windows platform when the project is not configured to use any build tool (ex. maven).

Details about issue

The reason for this issue is because gauge compiles the java files and move the classes to gauge_bin. The debug info in the classes does not include an absolute path of source file. So the source is unknown in the debug stack.
The debugger stops the location where it finds the source
A sample debug stack -

StepImplementation.setLanguageVowels(String) (Unknown Source:15)
NativeMethodAccessorImpl.invoke0(Method,Object,Object[])[native method] (Unknown Source:-1)
NativeMethodAccessorImpl.invoke(Object,Object[]) (Unknown Source:62)
DelegatingMethodAccessorImpl.invoke(Object,Object[]) (Unknown Source:43)
Method.invoke(Object,Object[]) (\rt.jar\java.lang.reflect\Method.class:498)
MethodExecutor.execute(Method,Object[]) (Unknown Source:38)
StepExecutionStage.executeStepMethod(MethodExecutor,Method) (Unknown Source:76)
StepExecutionStage.executeStep() (Unknown Source:69)
StepExecutionStage.execute(Spec$ProtoExecutionResult) (Unknown Source:51)
AbstractExecutionStage.executeNext(Spec$ProtoExecutionResult) (Unknown Source:24)
HookExecutionStage.execute(Spec$ProtoExecutionResult) (Unknown Source:43)
ExecutionPipeline.start() (Unknown Source:29)
ExecuteStepProcessor.process(Messages$Message) (Unknown Source:48)
MessageDispatcher.dispatchMessages(GaugeConnector) (Unknown Source:93)
GaugeRuntime.dispatchMessages(MessageDispatcher,GaugeConnector) (Unknown Source:115)
GaugeRuntime.lambda$connectSynchronously$1(MessageDispatcher,GaugeConnector) (Unknown Source:98)
1018298342.run() (Unknown Source:-1)
Thread.run() (\rt.jar\java.lang\Thread.class:748)

The 4th stack contains the source path so that's the file which will be opened.
Although the variables in the debug stack are correct.

As discussed with the team this a scenario where a user is not using any build tools (not recommended). So we will not be spending time to fix this and mark is as a known issue.

@BugDiver BugDiver closed this Jan 22, 2019

@BugDiver BugDiver removed the in progress label Jan 22, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment