Announcement

Collapse
No announcement yet.

Very unusual problem.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Steve Hutchesson
    replied
    Hi Michael,

    Its not like it matters as I found the line where the error occurred and GetLastError() indicated that it was a memory page fault so I had isolated the line and had at least some idea of what was wrong with it. It just happened the the index for the entry was out of place which was a left over of a mod I did some months ago and the reason why the link (in the app ) worked (at times) was the line further down the long list that gave a valid link. As the first link line was the error, just deleting it allowed the valid link to work correctly.

    The app is a help file engine and while I have compacted the number of location for each entry, I still have to put in 4 entries to get a new page working properly. The app displays RTF pages with cross links to other pages.

    Leave a comment:


  • Michael Mattias
    replied
    Code:
    lbl1:
    avxseg$ = resource$(RCDATA, 2022) ' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    MyEr$ = last_error_string
    MsgBox MyEr$
    lbl2:
    The resource$ notation is correct but when running the OS based LastError call, I get this error

    .
    You don't mean the Widows API call "GetLastError(), do you? That cannot reliably be used if mixed in with PowerBASIC intrinsics, especially for anything involving a string.

    FWIW, PB should* return some kind of ERR on the RESOURCE$() call; I don't see your code reading that, nor is any active error trap ('ON ERROR'... statement) shown.

    For that matter, if you built your executable with duplicate IDs for type RCDATA resources using '#RESOURCE' statements, that should* have been caught at compile time.

    MCM
    * should does not mean "does" .. I have found a number of PB intrinsics which don't always return a PB error.

    Leave a comment:


  • Michael Mattias
    replied
    .. stepped through I tracked where the app either crashed or displayed an error message.
    In general you need to be real careful and NOT assume that a program 'crashes' because of an error at that point. The actual cause of the crash may be an error hundreds or thousands of lines of code (source or object) from that "death point."

    Using the stepping debugger to "stop on untrapped error" is probably the closest you can come to finding the actual point of error... but bear in mind external calls (e.g to the WinAPI) will NOT trip this setting.

    Leave a comment:


  • Jim Fritts
    replied
    Glad you found it.

    Leave a comment:


  • Steve Hutchesson
    replied
    I found it, a duplicate entry with a non existent resource ID. Useful enough, I got some practice using the PB trace and isolated the line with labels.

    Jim, I have been using Win10 64 for about 5 years. I do have a nice Win7 64 box but don't use it much.

    Leave a comment:


  • Jim Fritts
    replied
    Steve,
    #RESOURCE RCDATA, ResID, "filespec.DAT"
    Returns predefined
    resource data.
    Syntax r$ = RESOURCE$(RCDATA, ResID)
    You are still using Windows 7, right?

    Leave a comment:


  • Steve Hutchesson
    started a topic Very unusual problem.

    Very unusual problem.

    I have been adding additional data to a help engine in the form of resource$ statements and have just found what looks like a limitation in how much memory the resource$ statement can handle. About 25% of the time that engine just exits with no explanation. I set up the following,
    Code:
      TRACE NEW "trace.txt"
      TRACE ON
    And stepped through I tracked where the app either crashed or displayed an error message.
    Code:
        lbl1:
    
        avxseg$      = resource$(RCDATA, 2022)      ' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    
        MyEr$ = last_error_string
    
        MsgBox MyEr$
    
        lbl2:
    The resource$ notation is correct but when running the OS based LastError call, I get this error.
    Code:
        Not enough memory resources are available to process this command.
    The actual amount of data is about 350k of RTF format text and this seems to be the problem.

    If the app does not crash, the text that the resource$ line activates works correctly and displays the RTF but at about 25% of the runs of the engine, it crashes trying to execute this line of code.

    Has anyone ever seen this problem before ? I would be interested if anyone has solved this problem in their own work.
Working...
X