| 
 | 
 | 
 
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    | 
		 
		
			
				
				
				
					
						  
						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
		
		
		
 |  
	| 
		
	 | 
 
 
 |  
  
 
	
	  | 
	 | 
	
		Heap errors behavior is dependent on target machine.
		By:  jfranks on Sat, 28 November 2015 14:03  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Sat, 28 November 2015 18:43  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  jfranks on Sat, 28 November 2015 22:37  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Sun, 29 November 2015 07:07  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Sun, 29 November 2015 12:53  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  jfranks on Sun, 29 November 2015 18:34  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Sun, 29 November 2015 18:48  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  jfranks on Mon, 30 November 2015 02:50  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Mon, 30 November 2015 10:03  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Mon, 30 November 2015 10:05  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Mon, 30 November 2015 10:45  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  jfranks on Tue, 01 December 2015 05:58  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Tue, 01 December 2015 19:48  
	 | 
 
	  | 
	 | 
	
		Re: Heap errors behavior is dependent on target machine.
		By:  jfranks on Wed, 02 December 2015 16:44  
	 | 
 
	  | 
	 | 
	
		[RESOLVED] Re: Heap errors behavior is dependent on target machine.
		By:  jfranks on Fri, 04 December 2015 15:29  
	 | 
 
	  | 
	 | 
	
		Re: [RESOLVED] Re: Heap errors behavior is dependent on target machine.
		By:  mirek on Fri, 04 December 2015 17:09  
	 | 
 
	  | 
	 | 
	
		Re: [RESOLVED] Re: Heap errors behavior is dependent on target machine.
		
	 | 
  
Goto Forum:
 
 Current Time: Tue Nov 04 06:55:35 CET 2025 
 Total time taken to generate the page: 0.04118 seconds 
 |   
 |  
  |