Verified Answers


If an answer to your question is correct, click on "Verify Answer" under the "More" button. The answer will now appear with a checkmark. Please be sure to always mark answers that resolve your issue as verified. Your fellow Community members will appreciate it!  Learn more

  • State Verified Answer
  • Replies replies
    7
  • Subscribers subscribers
    16
  • Views views
    271
  • Users 0 members are here
Related
Options

Debug Source Display has encountered a problem - Null argument

Martin Brunner

Hello there,

we are currently migrating from Visual Cobol for Eclipse 7 to Visual Cobol for Eclipse 9. A few users of our users have already installed the new Version Visual Cobol for Eclipse 9 (PU 04) under Windows.

Some of our users experienced the error  "Problem occured: 'Debug Source Display' has encountered a problem. An internal error has occured - Null argument" while debugging. While Debugging, a window pops up with that error message, and after closing the error-window, no more Cobol sources nor Cobol copies are displayed, but the debugger is still attached. Eclipse then asks for cobol copy (ALCTRCMA.cpy), which should be familiar, because it is already known to the project. The error window itself pops up, after taking a few steps (F5) in the Remote Debugging perspective.

I attached a screenshot of the issue in question. At the top you can see the error in the Debugging perspective. Then a new window pops up if I want to select a new context (doesn't help). At the bottom I attached a screenshot of the Cobol Copy in question, which you can see is available in the project. (The cobol/AL/cpy folder contains multiple Cobol copies, in the screenshot I'm only showing the Cobol Copy in question: ALCTRCMA.cpy)

So the debugging first starts off completely fine, after the "Remote source lookup creation" we can see our main source and we can also take a few steps in the running program.

Here's a rough explanation, what we can see and debug, before the error occurs: The main source has a "PERFORM XXX" statement, in the XXX section we have some, INITIALIZE, SET, CALL, IF ... MOVE ... END-IF statements. Until this point we are able to remotely debug the program with VC9. But then we have a (seemingly problematic) statement "EXIT" in the cobol program at the end of the XXX section - and after that we get the error 'Debug Source Display ... Null argument'

The error is replicable on my machine. The remote debugging of our project worked fine with MicroFocus Visual Cobol 7.

We are primarly using the "Remote COBOL Project " to import a LINUX Cobol project (that has already been compiled in linux) and then debug the Cobol programs, which are running under Linux. These steps worked very nicely with the previously used Visual Cobol for Eclipse 7 Version.

Some Information about the project:

- Remote COBOL Project file system: RSE using Micro Focus template [64 bit]

- After creating the project we disable the Remote COBOL Builder: Properties > Builders > uncheck "Remote COBOL Builder"

- We use the "COBOL Wait for Application Attachment", where we modify the Tabs "Source" (with our Remote Sources folder) and "Debug Symbols" (with our precompiled Debug symbols)

What product and version number are you using?

Windows: Version: 9.0.00170 Update level: PU 04

Linux:

- I tried "Micro Focus Visual COBOL Development Hub 7.0 - Patch Update 14" (pkg_312705) aswell as

- Micro Focus Visual COBOL Development Hub 9.0 - Patch Update 09 (pkg_358101)

OS:

Windows: Windows 10 Enterprise

Linux: I tried "SUSE Linux Enterprise Server 15 SP5" aswell as "SUSE Linux Enterprise Server 12 SP5"

Do you have any ideas, how we can resolve the issue ?

Thanks in Advance !

  • 0  

    Hello Martin,

     

    Thanks for posting to the Visual COBOL Community site, and for providing so much information about the issue. I have a couple of suggestions and comments about this.

     

    First, I think you mentioned that "some users" are having this issue. Are you saying that other users in your organization (who are using 9.0) are not encountering this issue? If so, are there any known differences about those users - such as when or how they were set up with the 9.0 product, or which 9.0 Patch Update they are using?

     

    Next, you should always use the same Version and Patch Update level on your Visual COBOL for Eclipse workstations as you have in your Visual COBOL Development installation on SUSE. Since you already have 9.0 Patch Update 9 available on Linux, I'd suggest upgrading the Windows installation to the same Patch Update. Make sure you have recompiled on Linux with 9.0 Patch Update 9, and then check to see if the issue still occurs.

     

    Finally, investigating remote Eclipse debug issues will likely require exchanging files that are not suitable for a public forum. If getting to the same 9.0 Patch Update level on Windows and Linux does not resolve the issue, please create a Support Case for this issue, and ask that it be assigned to Blair McDonald.

  • 0 in reply to   

    Hello Blair,

    thanks for your response.
    Other users are also experiencing the same errors, but in a different way. Let me try to clarify:
    - For me, after I get the error "Debug Source Display has encountered a problem", I can't view anymore sources while debugging.
    - Another colleague also runs into the same error message, but after the error message, he is still able to debug further (and see the lines of other sources of the project while debugging - which is less critical because then he can just ignore the error).


    Our users are testing on the same Linux Machine (so with the same VC Version, currently VC 7 PU14). We have a Software Distribution System for Windows Software, so our Windows VisualCobol installation should be the same version.
    I just made sure this is the case: The colleague uses exactly the same MicroFocus Visual Cobol Version "Version: 9.0.00170 Update level: PU 04" under Windows as me.

    In another debug attempt I just had, I found this following stacktrace next to the error message.
    Can a developer please have a look on this, because apparently there are also MicroFocus Packages listed - com.microfocus.eclipse ? I would be very grateful !
    org.eclipse.core.runtime.AssertionFailedException: null argument:
        at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:88)
        at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:76)
        at org.eclipse.jface.text.rules.FastPartitioner.connect(FastPartitioner.java:135)
        at org.eclipse.jface.text.rules.FastPartitioner.connect(FastPartitioner.java:124)
        at com.microfocus.eclipse.editor.internal.common.AbstractParsingEditor.installDocumentPartitioner(AbstractParsingEditor.java:586)
        at com.microfocus.eclipse.editor.internal.common.AbstractParsingEditor.limitedDoSetInput(AbstractParsingEditor.java:465)
        at com.microfocus.eclipse.editor.internal.common.AbstractParsingEditor.doSetInput(AbstractParsingEditor.java:433)
        at com.microfocus.eclipse.editor.internal.common.AbstractCobolEditor.doSetInput(AbstractCobolEditor.java:424)
        at org.eclipse.ui.texteditor.AbstractTextEditor.lambda$1(AbstractTextEditor.java:3162)
        at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:434)
        at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:352)
        at org.eclipse.ui.internal.WorkbenchWindow.lambda$7(WorkbenchWindow.java:2345)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:74)
        at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2343)
        at org.eclipse.ui.texteditor.AbstractTextEditor.internalInit(AbstractTextEditor.java:3179)
        at org.eclipse.ui.texteditor.AbstractTextEditor.init(AbstractTextEditor.java:3204)
        at com.microfocus.eclipse.editor.cobol.CobolEditor.doSuperInit(CobolEditor.java:303)
        at com.microfocus.eclipse.editor.cobol.CobolEditor.init(CobolEditor.java:288)
        at org.eclipse.ui.internal.EditorReference.initialize(EditorReference.java:353)
        at org.eclipse.ui.internal.e4.compatibility.CompatibilityPart.create(CompatibilityPart.java:344)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        [truncated 75 more lines]
        
    There is also another error (which might just be a consequential error), that I still wanted to adress, because it might give us a slight hint at what is going wrong.
        'Debug Source Display' has encountered a problem.
        An internal error has occured.

        Cannot invoke "org.eclipse.jface.text.IDocument.containsPositionCategory(String)" because "this.fDocument" is null    
        
    Since we have a Software Distribution System for our Windows Software, I can't easily install VC9 PU9 on my Windows Machine.
    But what I can do instead, is to use the currently installed VC9 PU4 (Windows) and try debugging under Linux (also with VC9 PU4 instead of PU9).
    So i installed VC9PU4 under Linux.
    COBDIR set to /opt/microfocus/VisualCOBOL9PU4
    martin.brunner@XXXXXXXX:~> cob -V
    version @(#)cob.c       9.0.0.68
    PRN=KXCSU/AAF:Ao.U4.13.04
    PTI=64 bit
    PTI=Micro Focus Visual COBOL Development Hub 9.0 - Patch Update 04
    PTI=Patch Update 04
    PTI=pkg_339842
    PTI=MFInstaller
    I see no work (see `cob -?' for help)

    Then I recompiled our linux project and after recompiling I created a new Workspace in Windows and created the Remote COBOL Project.
    Unfortunately now I get the error message, that debug symbols can not be resolved, eventhough the project structure is the same and I recreated the Remote COBOL Project:
    Loaded: [User Module]XXXXXXXXXX- No symbols found in: XXXXXXXX.idy
    I can see the UserModule.idy file in the cobol/debug folder (f.e. 182 kB, modified 12.06.2024 16:47:05)
    Thats the same folder I configured in the Cobol Wait For Application Attachment under the Debug symbols. I will have another look at this tomorrow.

    In the meantime, could you please have another look on the stacktrace given above ?
    Thanks so much !

    Yours sincerely
    Martin

  • 0   in reply to 

    Hello Martin,

     

    Thanks for your update, and for letting us know that you've made the installations match; you now have 9.0 Patch Update 4 on both Windows and Linux. Just FYI, using different Versions and/or Patch Updates is definitely not supported.

     

    One my colleagues noticed that the timestamp you showed for an .idy file was seemingly from June 12:

     

    Loaded: [User Module]XXXXXXXXXX- No symbols found in: XXXXXXXX.idy

    I can see the UserModule.idy file in the cobol/debug folder (f.e. 182 kB, modified 12.06.2024 16:47:05)

    So you might want to confirm that when you rebuilt the COBOL programs on Linux, these were *all* built for debugging (i.e. with -g flag included if compiling with the cob command). I would expect all of the .idy files for COBOL programs to be updated to the current date and time when a build is completed. Since you point to a particular folder for the Debug symbols, you might try deleting all of the files there, and then rerun your build to re-create them.

  • 0 in reply to   

    Hello Blair,

    thank you for pointing that out, that was a typo ...

    12. Aug 16:47 is the correct date copied from the ls command of the debug folder. I rebuilt the project just to be sure.

    ls -l /home/martin.brunner/.../debug | grep -v "13. Aug" shows no file matches now. (13. Aug 07:52 is now the copied date)

    As far as I can see, our build scripts are already consistently using the -g flag:

    cob XXXXXXXX.cbl -g -c -x -C ...

    and

    Using cob -g -x -o ... -L...

    With Visual Cobol 7 the remote debugging of the project worked fine. Could a developer please take a look at the error/stacktrace, I attached above, that'd be great. Thanks !

    org.eclipse.core.runtime.AssertionFailedException: null argument:

    and

    Cannot invoke "org.eclipse.jface.text.IDocument.containsPositionCategory(String)" because "this.fDocument" is null    

  • 0   in reply to 

    Hello Martin,

     

    Here is the response about the Stack Trace:

    The stacktraces describe the process of loading/unloading a content into an opened Eclipse editor view. For some reason, the file that is opened in the editor does not have an associated "document" that represents text providing support for positions, partitioning, text manipulation, etc.

    As to why it does not have a document, that is not clear.

     

    The complexity of this issue requires a Support Case to properly investigate it. Happily, it appears that a Support Case may have already been opened for this issue by one of your colleagues. If that's correct, please work with your colleague to investigate the issue through the Support Case.

  • 0 in reply to   

    Hello Blair,

    thank you very much for your responses and the initial analysation of the issue. We will now continue trying to resolve the issue via the already opened Support Case.

  • Verified Answer

    +1

    For anyone running into the same issue. We fixed the issue by:

    - Setting project type to SSH (instead of RSE): Right click on the "Remote COBOL Project" > Remote Settings ... > Connection mode: SSH (radio button)

    - and modifying the "Wait for Application Attachment" debug Configuration: Debug Configurations .... (bug symbol) > Choose your Wait for Application Attachment Configuration > "Source" Tab > Remove all entries and Add... > Cobol-Project > Choose the "Remote COBOL Project" (whatever your project name is - instead of what we had in the past - Remote File System Directory )

    This works fine with VC7 aswell as VC9. However we'd still be interested, why our settings from VC7 result in this error while debugging with VC9 (Settings in the past were - Connection mode: RSE and - Debug Configuration Source Remote File System Directory)

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.