Re: string length on Mac

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