Re: string length on Mac

Valgrind can be pretty awesome.

Valgrind generally adds 45 minutes to program startup unless your 
computer has at least 2 more core and 12 GB of RAM than it was 
previously using. When there is no other option it can be a useful tool.

Not FX related, but funny (now that it is over) story.

When I was helping create the first one of these for Welch Allyn

https://www.hillrom.com/en/products/connex-spot-monitor/

We had a coding/logic program where it was taking 10 minutes to load. 
Vikram decided we should use Valgrind. He spent a couple of hours 
getting the application built for Valgrind on target then started it on 
Friday afternoon. When he came in a little after 9am on Monday it 
__still__ hadn't finished the startup process.

Valgrind is a good tool, but you need an extreme amount of "spare" 
horsepower to run it. That's one of the reasons I keep a trusty old HP 
z820 around. 24 physical core and 120 physical GB of RAM. If I get in a 
Valgrind situation, that's the machine I use. I also use it for Yocto 
builds for the same reason. You can find them online pretty reasonable 
now because the CAD workstation people have moved on to dramatically 
more expensive machines.

Just my 0.0002 cents.

On 4/16/2024 10:10 PM, Jeroen van der Zijp wrote:
> On Tue, 16 Apr 2024 17:59:12 -0500
> Roland Hughes via Foxgui-users <[email protected]> wrote:
>
>> I haven't used Fox in a long time, but I'm older than dirt. Please allow
>> me to share a story that may or may not have anything to do with your
>> problem.
>>
>> Back in the days of DOS we had real compilers and real programmers, then
>> we had Borland and those who used it. Borland "developers" spread like a
>> pandemic throughout the industry. Since most of us were getting source
>> code via BBS and long distance calls via modem, if you unzipped some
>> source and the comments said it was developed using Borland, you just
>> deleted everything. It was going to be faster to write it yourself than
>> fix their "working, fully tested" code.
>>
>> Borland, by default, automatically initialized everything. Real
>> compilers did not. Some didn't even initialize stuff when compiling in
>> debug mode. Borland users were just hacks and their stuff would crash
>> all over the place when compiled with a real compiler. You could not
>> port it to another platform to save your ass.
>>
>> I took you on that picturesque journey down memory lane because what you
>> describe is ___exactly___ the kind of Mystery Crash we would get back
>> then. No, you aren't using Borland . . . but
>>
>> 1) Check your compilation switches, ALL of them, even the ones (if any)
>> Fox turns on without telling you.
>>
>> 2) On the Linux platform, turn off any compiler switch that initializes
>> anything for you so you can make it crash on Linux.
>>
>> Once it crashes, if you are using Ubuntu or Linux Mint (or a Linux based
>> on either) read this post:
>>
>> https://www.logikalsolutions.com/wordpress/information-technology/core-dumps/
>>
>> That will tell you how to enable core dumps. Then this post:
>>
>> https://www.logikalsolutions.com/wordpress/information-technology/core-dumps-2/
>>
>> Which will tell you how to use GDB within Emacs to debug a core dump.
>>
>> I'm 99.999% certain you have one of two problems.
>>
>> *Most likely:* as was eluded to in previous message, you somehow have a
>> logic path that is attempting to utilize an uninitialized string. If you
>> really are dying on length() you are dying on garbage that equates to a
>> really big binary number for the length because it has "whatever" was
>> left over in RAM.
>>
>> *Second most likely:* You are using a pointer to "something else" that
>> happens to point to where your string got allocated. You copied a big
>> block of something there and now your string has garbage for the size
>> and the length is larger than your physical memory.
>>
>> *Third most likely:* You returned a string ___ that was locally
>> allocated on the stack as a local variable___ via reference or address.
>> Mac re-used that chunk of stack but the other two platforms hadn't
>> gotten around to it yet.
>>
>> PC-LINT used to be an awesome product for finding most of these
>> problems. I assume it still is, but now it isn't a $350 tool you keep in
>> the toolbox because they charge your first born child and 3 critical
>> bodily organs for it.
>>
>> CppCheck "might" help you but the "free" version is really neutered. A
>> static analysis tool really could help you find some of these. Use the
>> Wikipedia page at your own risk.
>>
>> https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
> As a suggestion, perhaps valgrind (if it works on that system) can illuminate
> the issue.  At least on x86 its often great to spot memory overwrite issues [
> which is what this looks like].
>
> Finally, try if compiling with different options (debug vs. release), etc.
> makes a difference.
>
> Run the code in the debugger, and set breakpoint prior to the offending
> statement [if you can at least determine where that is].
>
>    -- JVZ
>
>
>
> _______________________________________________
> Foxgui-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/foxgui-users

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog


-- 
This email has been checked for viruses by Avast antivirus software.
www.avast.com