Custom Query (26 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (19 - 21 of 26)

1 2 3 4 5 6 7 8 9
Ticket Resolution Summary Owner Reporter
#25 fixed Potential memory leak Andreas Schnellbacher abwillis
Description

I ran cppcheck looking for possible uninitialized variables as I have seen crashes when doing a lot of scrolling. I did not find any but found a potential memory leak. I'll let you evaluate and decide if this is meaningful.

Index: src/gui/nepmdlib/nepmdlib.c
===================================================================
--- src/gui/nepmdlib/nepmdlib.c	(revision 2946)
+++ src/gui/nepmdlib/nepmdlib.c	(working copy)
@@ -1032,7 +1032,7 @@
          HCONFIG        hconfig;
 
          CHAR           szResult[ 20];
-         PMODEINFO      pmi = malloc( 1024);
+         PMODEINFO      pmi = NULL;
 
 FUNCENTER;
 
@@ -1076,6 +1076,8 @@
    } while (FALSE);
 
 FUNCEXITRC;
+if (pmi)
+  free( pmi);
 return _getRexxError( rc, pszBuffer, ulBuflen);
 }
 
#26 fixed Removing a key from its parent RegContainer value removes a zero char too much Andreas Schnellbacher Andreas Schnellbacher
Description

After executing

NepmdDeleteConfigTree \NEPMD\User\AutoRestore

the section RegKey is OK, but in RegContainer, the entry for \NEPMD\User was changed from

AutoRestore.AutoSave.Backup.Colors. ... .Toolbar.

to

AutoSaveBackup.Colors. ... .Toolbar.

(zero chars replaced by single dots).

The faulty function is _removeKeyFromContainerList of libreg.c, which exists for a long time.

The removed RegKeys are:

\NEPMD\User\AutoRestore\Ring\LoadLast
\NEPMD\User\AutoRestore\Ring\MaxFiles
\NEPMD\User\AutoRestore\Ring\SaveLast

The removed RegContainer keys are:

\NEPMD\User\AutoRestore\Ring
\NEPMD\User\AutoRestore

It may have relevance that two container levels were removed.

Luckily, this bug didn't appear until now. It has to be fixed before the deletion of a tree will be added to ImportUserTextConfig, triggered by a DELETE: value in user.cfg.

#27 fixed Assist: Improve scanning of MLC array Andreas Schnellbacher Andreas Schnellbacher
Description

Assist behavior is about 100 times too slow. Tests show that parts were executed multiple times.

Improvements are:

  1. In locateMLC, the search can be improved: Instead of simply starting at item 1 and advancing the counter by 1, it should start at the middle and then either decrease or increase it be the half value. (This is the largest improvement and a safe method has to be created.)
  1. In defproc locateMLC, fix multiple calls of the loop starting with 'do j = 1 to MLCListCount'. It apparently depends on the amount of MLCs in between a bracket start and end area. (This would be a large improvement and the culprit is currently not found.)
  1. locateMLC itself is called two times, for the opening and for the closing token (e.g. bracket). The second call is caused by a bracket-matching command. The corresponding token is highlighted then. (A minor improvement would be to start the search for the matching token at the pos. of the starting token instead of at the middle.)
  1. Improve other code, like using faster search options (g instead of x) if possible and optimize nested IF conditions in locateMLC. (This saves only about 20 % of the time.)
1 2 3 4 5 6 7 8 9
Note: See TracQuery for help on using queries.