C / C++ / MFC

Re: Heap Corruption Durning Streamin think I found it

16-Jan-23 16:20

it was a storage overlay I'll explain I had a global variable. the kept track of the number of records are but even so the exception didn't happen at that point.

I ended doing a binary search from thousands of records.

I had allocated 63 bytes assembler of storage. e,g a dc statement that defined 90

thing is the exception doesn't happen. right away its way down the road and you have no idea where those _crtcheckmemory don't really help.

jschell17-Jan-23 4:12

jschell

17-Jan-23 4:12

ForNow wrote:
right away its way down the road

Yep that is how memory (heap) corruption works. You broke the heap at that point. Then somewhere after it something went to use the heap and at that point the data was bad.

Additionally the behavior that happens could be almost anything. Depends on what the actual data (bad) was in the heap and what it was attempting to do with it at that point, and even what was calling it.

Re: Heap Corruption Durning Streamin think I found it

ForNow17-Jan-23 4:17

17-Jan-23 4:17

When I overlay storage on z/os I get a s0c4 pic 10,11 etc my recovery gets control and I can pretty much determine what happened

I had a record count at of x196e

It actually happened at record x1905 had no idea where to look inserted crtmemory check at my new’s and map::insert

Finally got it wondering if there is easier way to figure out storage/heap issues thank you

15-Jan-23 15:45

15-Jan-23 15:45

Message Closed

modified 15-May-23 19:06pm.

Re: Why #if 0 ... #endif

Mircea Neacsu15-Jan-23 15:57

Mircea Neacsu

15-Jan-23 15:57

It's a way of commenting out a block of code. In your case, seems like a way to eliminate some debug messages.

Mircea

15-Jan-23 16:43

15-Jan-23 16:43

Message Closed

modified 15-May-23 19:06pm.

Re: Why #if 0 ... #endif

CPallini15-Jan-23 20:36

Where does this .exe store its pane layout?

15-Jan-23 20:36

Quote:
BUT does
#if 0

evaluates to "true " ?

0 evaluates to 'false' see, for instance, the bottom line of this page: If (The C Preprocessor)[^]

Quote:
I have been using

#ifdef BYPASS

#endif

where BYPASS is not defined
to skip the enclosed block

The compiler skips the code if BYPASS is not defined (that is, the 'condition' is 'false').

"In testa che avete, Signor di Ceprano?"
-- Rigoletto

Bardo Mueller15-Jan-23 9:09

Bardo Mueller

15-Jan-23 9:09

I am using a (portable?) exe, not requiring an install.

[DELETED]

It allows to drag its panes, which it remembers between sessions.
The pane layout is now in a corrupted state, one pane does not show up and I would like to "reset" it.

I was looking in the following places:
- no hidden file with the binary
- no registry entry
- no data in AppData
- no change upon deleting the directory and unzipping again.

Any idea?

Re: Where does this .exe store its pane layout?

OriginalGriff15-Jan-23 9:10

OriginalGriff

15-Jan-23 9:10

Go back to the manufacturers and ask them: they are the only people with the source code, so they are the only ones who can help you fix it.

"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!

Re: Where does this .exe store its pane layout?

Bardo Mueller15-Jan-23 11:30

Bardo Mueller

15-Jan-23 11:30

OK, found a solution:
- install Process Explorer
- add Evan.exe process/subprocess monitoring
- Filter subsequently for file/registry access
- Found

HKCU\SOFTWARE\EVAN

with size data
- delete this key in regedit.

14-Jan-23 5:42

Re: Why "so many " - include , forward declaration...

14-Jan-23 5:42

Message Closed

modified 15-May-23 19:06pm.

CPallini14-Jan-23 7:23

Re: Why "so many " - include , forward declaration...

14-Jan-23 7:23

Forward declarations have their use (without them that code wouldn't compile).
You might find an explanation here: Forward declaration - Wikipedia[^].

"In testa che avete, Signor di Ceprano?"
-- Rigoletto

Richard MacCutchan14-Jan-23 22:25

Richard MacCutchan

14-Jan-23 22:25

I would assume that the forward declarations are required because you have:

C++

public:
    QBluetoothDeviceDiscoveryAgent *discoveryAgent;
    QBluetoothLocalDevice *localDevice;

in your class. And these two pointers refer to the QBluetoothDeviceDiscoveryAgent and QBluetoothLocalDevice classes. However, you also have the include files:

C++

#include "QtBluetooth/qbluetoothdevicediscoveryagent.h" // ?
#include "QtBluetooth/qbluetoothdeviceinfo.h"
#include "QtBluetooth/qbluetoothlocaldevice.h"  // ?

before your class definition, where one would assume that the aforementioned are actually declared. So maybe they are not really needed.

Re: Why "so many " - include , forward declaration...

jschell15-Jan-23 8:00

jschell

15-Jan-23 8:00

Member 14968771 wrote:
Why so many

That is usually a subjective thing. In general it should not be required.

But what happens, over time, is that as complexity grows so does the definitions.

And there are only two choices
1. Include the actual source of the definition
2. Include a short cut.

The first solution, in general requires that the compiler reread (parse, tokenize, etc) the full included source files every time and then likely the includes for those as well and that can continue for a while. That takes time. Compilers, now, tend to attempt to optimize that by using various caching strategies. But, at least in the past, some of those were less than reliable.

So people might want to avoid that by using short cuts. Thus the compiler can do far less work. And that is what that is.

Ideally of course the design should minimize all of that. Even at times to the point of perhaps reducing clarity. One trick that I used to use was to create two includes. One that was only for public consumption and the other for internal consumption (for example internal structs) and then the public visible items used something like a 'void *' and then I used casts for the internals. That did allow the external include to be smaller it size but it was a solution that only worked in some cases.

15-Jan-23 16:56

Re: Why "so many " - include , forward declaration...

15-Jan-23 16:56

Message Closed

modified 15-May-23 19:06pm.

jschell17-Jan-23 3:33

jschell

17-Jan-23 3:33

Member 14968771 wrote:
even with the comment "things grow in complexity "....

Have you worked with legacy systems? Systems that have been in continued use for 20 years with ongoing changes throughout that time period?

And for a product that has started with a small customer base but which has grown to many?

Google for example...

"span a whopping 2 billion lines of code that stretch across 1 billion files and require 86 terabytes of storage,"

Don't you suppose there are some less than ideal code in that?

Or if you prefer GCC is roughly 15 million lines of code.

Member 14968771 wrote:
and that should be all ( objective) what is needed

That is of course specifically subjective.

And you will not find any non-trivial application code base in C++ where the vast majority of files follow that model. Most will have many include files. Sometimes there are even include files that are nothing but a container for other include files (and that can recurse.)

CRichEditCtrl size limit

ForNow11-Jan-23 15:22

Re: CRichEditCtrl size limit

11-Jan-23 15:22

Hi

I resolved all the initial heap errors still receiving some but I think I know the cause the Assembler listing I am streaming is 153 pages with 54 lines to page and about 130 characters across so that's a little bit over a meg large, Can I use LimitText to give myself the space?

Mircea Neacsu11-Jan-23 15:47

Mircea Neacsu

11-Jan-23 15:47

Never tried but it should work.

See: EM_EXLIMITTEXT message (Richedit.h) - Win32 apps | Microsoft Learn[^]
and https://stackoverflow.com/questions/180853/cedit-control-maximum-length-in-characters-it-can-display[^]

Mircea

Re: CRichEditCtrl size limit

ForNow11-Jan-23 15:48

Bitmaps, device dependent vs device independent, which is faster (or better)?

11-Jan-23 15:48

Thanks

Member 1507871611-Jan-23 10:57

Member 15078716

11-Jan-23 10:57

I am working at blitting to back frame buffers a changing variety of bitmaps to create animations. When completed, that would be sent to the screen. I want to do this with minimum processing and minimum RAM.

Svetoslav Chekanov, on another page Fast 2:1 Image Shrink (Scale Down)[^] said,

Quote:
Device dependent format is blitted faster to the screen.

I did not know that. I have been using Device Independent because it seemed to be easier to work with. I will now consider this Dependent vs Independent.

I found a discussion with some interesting observations. C++ Windows API: Is there any alternative of the SetDIBits for device-dependent Bitmap?[^] In that I found:

Quote:
The difference is insignificant, more than swamped by the time it takes to
copy the bitmap to the frame buffer.

May I have some feedback on this "is insignificant" comment (from the Windows API link) if it is correct or not?

I also read on that page,

Quote:
In a DIB, each scanline is always a multiple of 4 bytes. In a 24-bit DIB,
that means you will have extra padding bytes unless the width is a multiple
of 4.

I did not know that. I will now have that to consider.

Looking forward to learning more about this.

Re: Bitmaps, device dependent vs device independent, which is faster (or better)?

CPallini11-Jan-23 20:43

what I am doing regarding Heap corruption

11-Jan-23 20:43

Well, they claim the device independent one are faster (Bitmap Classifications - Win32 apps | Microsoft Learn[^].
You could arrange a test in order to have experimental evidence.

"In testa che avete, Signor di Ceprano?"
-- Rigoletto

ForNow10-Jan-23 15:33

Re: what I am doing regarding Heap corruption

10-Jan-23 15:33

Since many have been so kind as to help me out i will spell out exactly what I am doing

The Windows Program is a client to Z/os Mainframe program. I download a file (variable blocked) the output of a MainFrame Assembler program listing. This on the mainframe is called a sysadata file.

The Windows exe calls the dll to basically convert the binary representation of the listing into readable format

The routine I having the exception in is a subroutine called by another routine in the DLL The file i/o is done in the DLL.

I think I am going to take out all the storage allocation out of the DLL is just causing me all sorts of problems the structure I'll pass from the exe to the dll will

have the maximum amount of storage I need I do a number of STL objects such as maps in the DLL basically a number of map objects I have already generated them I hoping that when

the exe needs the information from the DLL I dont have issues referencing them

CPallini10-Jan-23 20:08

Re: what I am doing regarding Heap corruption

10-Jan-23 20:08

Quote:
The Windows exe calls the dll to basically convert the binary representation of the listing into readable format

A simple workaround would be moving that code inside the executable.

"In testa che avete, Signor di Ceprano?"
-- Rigoletto

ForNow11-Jan-23 1:33