Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Bug Reports / [ANNOUNCEMENT] Bug Reporting Guidelines

Retired Moderator
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Mar 2008 11:41
Here are a few guidelines to help both you and us with your bug posts.

1) This forum is for DBPro compiler bugs and official plug-ins only.

Things we don't want to see in this forum:
- IDE bugs (see the other sticky post regarding editor problems)
- DarkBasic Classic bugs
- Questions about problems in your own code (the DBPro forum is the best place for those).

2) Please limit your bug reports to one bug per post.

If you report more than one bug per post, it is difficult for us to confirm or reject a single part of your bug report. We may also miss a part of your report.

3) Post source code.

A bug report with attached source code is more likely to be dealt with earlier than a report without source. This also makes it easier for us to confirm your bug.

We can also use it later to ensure that the bug has been cleared when a new Update is released.

4) Keep your code short.

Keeping your demonstration code short will allow us to see the problem more quickly. It is also a good way to ensure that the bug you have found is actually a bug and not a coding error.

5) Include your media.

If your bug requires media, then you should include it with your bug report and upload it to the forums. If your file is too large to upload, then just ask if you can email it to one of the moderators. Please don't send media to us without asking first.

6) Details to include in your post.

Please include all relevant details:
- Operating system and service pack level
- Processor model/speed and system RAM
- Video card make/model/memory and driver version
- Update level of DarkBasic Professional, and the editor

7) If the error is yours...

If you subsequently find the error is of your own making, please post a follow-up reply to save our time.

8) Check the help files.

If the problem is with a particular command, check the help files for those commands first to make sure that the command is definately not working as intended.

9) Check for wider problems

For example, does the problem occur only with certain media, or only on a particular operating system? If you have time to check this will help narrow down the problem area.

Retired Moderator
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 24th Mar 2008 11:58 Edited at: 24th Mar 2008 11:58
Here are some recent examples that I prepared for Lee for the 6.7 bug fix release, simplest first. All were originally based upon existing bug reports in this forum which were re-written to make the bug easier for Lee to see and confirm a fix on.

Example 1.
Compile and run - the code will fail at runtime with 'Runtime Error 7002 - Could not load mesh at line 3'
Should report 'Runtime Error 7007 - Object already exists at line 3'

Example 2.
Run the code. Press space to add another 100 sprites and hold the key down. On occasions, not all sprites will be displayed during the sync. Release the space key and they all appear.

This only appears to happen with multiples of 100 sprites.

Example 3.
The OBJECT IN SCREEN function is inaccurate.

The code is designed to ensure that the object is always in wireframe mode if the object is visible.
1. Position the camera within the sphere. Rotate the camera within the sphere. Wireframe mode will pop on and off even though the object is always visible.

2. Press ENTER to reset the camera position & rotation. Rotate the camera so that the object and the bounding box is off-screen. Note that the OBJECT IN SCREEN result in the top-left of the display will still report '1'.

Example 4.
Allocating an array of strings - the memory for the strings is not recovered when the array is undim'd or emptied. The memory for the actual array storage is returned Ok.

This was originally rejected by Lee - he wasn't convinced:
Quote: "The issues regarding memory leaks reported using SMEM and Task Manager are not so clear cut, as both these do not reflect the true heap consumption of a DBP app, simply a determination of available physical memory on the overall machine."

Eventually, I managed to convince his with the following:

The code attached allocates a 100MB string, dims a string array, copies the string into it, then undims the array.

If there's no leak, then the code should run forever - there's going to be a little heap memory fragmentation, but not enough to stop this program until it has run though at least a couple of thousand loops (windows uses a best-fit allocator IIRC).

If there is a leak, the program will exit before it gets to 2000MB allocated and will probably exit earlier - mine dies after allocating 1200MB and when attempting to create the array for the next pass.

The last turned into a bit of a story, but it shows sometimes how far you may need to go to prove a bug is really there.

Login to post a reply

Server time is: 2019-06-19 07:05:44
Your offset time is: 2019-06-19 07:05:44