Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Heap errors behavior is dependent on target machine. (Heap errors occur on one machine but not on a another.)
Re: Heap errors behavior is dependent on target machine. [message #45541 is a reply to message #45540] Sat, 28 November 2015 22:37 Go to previous messageGo to previous message
jfranks is currently offline  jfranks
Messages: 36
Registered: September 2014
Location: Houston, Texas
Member
Thank you for helping us.

Q1. Does the problem occur with e.g. examples/UWords too?

A1. No, the problem does NOT occur with examples/UWord. I compiled
and ran this on machine 'B' and everything worked correctly.
I was able to enter some text, save it to a qtf file, exit the
program without any issues.

Q2. Have you tried memory breakpoint?
http://www.ultimatepp.org/srcdoc$Core$Leaks$en-us.html

A2. Yes we have done that. Memory breakpoint #1 was used to generate
the snapshot of the call-stack (uploaded previously), while in
the debugger.

It seems strange memory break-point #1 was not hit immediately
when the application was run. Instead, break-point #1 did not
engage in the debugger until we tried to exit the application. I
expected it to be the other way around.

Q3. Can you post a couple of lines of log with leak with smallest
breakpoint number?

A3. Yes, I have done that on this response. Also, I was in error when
I said that there were more than 2200 items in the log file.
Actually, there are only 355 items each time we run the
application and then exit. I ran wc on the log-file erroneously
thinking that each line was a memory leak (too many long hours).

174 items + <size 828>
174 items + <size 812>
7 items <various sizes>

I've included the log-file with comments that show where patterns
repeat until the final 7 items are reported. I have not been able
to figure out anything relating to the repeating patters, however,
the last 7 items have to do with a shared library that manages
the serial ports. Each one of the 7 items is caused by a stdc++
string that is part of that library.

As an experiment, I modified that shared library to use const char*
instead of stdc++ strings. For example:

#if 0
const std::string ERR_MSG_PORT_NOT_OPEN = "Serial port not open." ;
const std::string ERR_MSG_PORT_ALREADY_OPEN = "Serial port already open." ;
const std::string ERR_MSG_UNSUPPORTED_BAUD = "Unsupported baud rate." ;
const std::string ERR_MSG_UNKNOWN_BAUD = "Unknown baud rate." ;
const std::string ERR_MSG_INVALID_PARITY = "Invalid parity setting." ;
const std::string ERR_MSG_INVALID_STOP_BITS = "Invalid number of stop bits." ;
const std::string ERR_MSG_INVALID_FLOW_CONTROL = "Invalid flow control." ;
#else
const char* ERR_MSG_PORT_NOT_OPEN = "Serial port not open." ;
const char* ERR_MSG_PORT_ALREADY_OPEN = "Serial port already open." ;
const char* ERR_MSG_UNSUPPORTED_BAUD = "Unsupported baud rate." ;
const char* ERR_MSG_UNKNOWN_BAUD = "Unknown baud rate." ;
const char* ERR_MSG_INVALID_PARITY = "Invalid parity setting." ;
const char* ERR_MSG_INVALID_STOP_BITS = "Invalid number of stop bits." ;
const char* ERR_MSG_INVALID_FLOW_CONTROL = "Invalid flow control." ;
#endif

I compiled and installed the modified serial port shared library
and then re-tested the application. Those last 7 items
disappeared! Also, the other items in the log file that repeated
174 times now repeat only 124 times. I don't know why that changed.

There must be a clue here.

-- Jeff
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: OpenGL test
Next Topic: Eigen updated and new FFT demo included
Goto Forum:
  


Current Time: Thu May 23 14:33:19 CEST 2024

Total time taken to generate the page: 0.01532 seconds