[M3devel] paths too truncated in assertion failures

[Jay K]

It isn't perfectly scientific, as even full paths on a machinecan have variable meaning through time.

For example, I can delete some source, put other source in its place,similar or different.

And on Windows there is the "net use" feature where drive lettersmap to the network. Then you delete the use, and make another one,same letter, different place.

Similar to mounting on Unixy systems.

Here is another story in this area.Hopefully I have my facts correct.Perhaps it is just apocryphal and I filled in details to suit my agenda.We can double check it all with a bit of time.

Visual C++, has, like any other system, some value for __FILE__and some values in the debugging information.

A long time ago, they were both whatever you passed on the command line.

At some point, a switch was added /FC that meant "full path the valuesin the debugging information". I believe this was added around Visual C++ 5.0.Later however, it was realized, that should always be how it works. The switchno longer does anything.


Or maybe /FC still serves to full path __FILE__ but no longer has anyaffect on debugging information.I'd have to go back and try every compiler I have to verify.

So, I think this actually motivate my other point from years ago,which is to full path the file names in the debug info, but not necessarily here.But I want both. :)

I debug a lot of stuff, and it is unavoidably difficult, but some thingsjust make it unnecessarily more difficult and tedious.

We should actually be recording crcs of source files and the assertcan go off and find the source and report if it matches.Or at least the assert can report the crc and user can verify it himself.i.e. once an assert fails, you can't do much reliably.

And yes, when there is no CM3_ROOT or such, unclear what partof the path to truncate.Which motivates the other option -- don't truncate anything.

I believe the names have to be unique "across the link".Visible or not, I'm not sure it matters.I don't believe we use the "static" feature of C/.obj files,so even non public functions, and the globals, are in a shared globalnamespace.
And with dynamic linking, you can't be sure they don't surviveinto the dynamic link search space at least on Unixy systems..
 - Jay



> Date: Sun, 30 Aug 2015 12:26:21 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] paths too truncated in assertion failures
> 
> I too have long wished for a longer path in these messages.  Although
> all source files in a package are required to have unique simple names,
> I doubt this is true between packages, except for visible interfaces.
> Even when unique, unless you have it all memorized, it is just an extra
> step to find a source file from only a simple name, when you are trying
> concentrate on the bug.  "../src/" usually provides no information.
> 
> I would be happy if the paths only went back as far as, say, cm3, for
> things in the repo, but how would we define where to stop for outside
> code?  In a way, I think a full path as on the machine where the program
> was compiled might be more helpful anyway.  Otherwise, that is really lost
> information, if you have any reason to care about it.  A partial path
> that translates in an apparent way from the compiling to the executing
> machine could even be misleading, as the files could be quite different.
> 
> OTOH, this can happen even when it's all the same machine, though probably
> less likely.
> 
> On 08/29/2015 05:12 PM, Jay K wrote:
> > These messages:
> >
> > ***
> > *** runtime error:
> > ***    <*ASSERT*> failed.
> > ***    file "../src/convert/Convert.m3", line 47
> > ***
> >
> >
> > 1) It should really be a full path.
> >
> > I know people will disagree with me.
> > You want more commonality across machines.
> > I'm not sure that is worth it.
> > In particular, debuggers always work more easily with full paths, for local private builds.
> > Hopefully for debugging someone else's, some search path
> > with "prefix replacement" is viable.
> > But debugging your own build is more common and ideally
> > no special setting is needed to make that work.
> >
> > Yes, full paths could "leak" across machines but I think that is ok.
> >
> > I did work on this long ago but people disagreed with at the time.
> >
> >
> > 2) We could/should trim the root of the git checkout, so it says
> > e.g. m3-sys/m3front/src/convert/Convert.m3 if that is easy.
> >
> >
> > Some C compilers have that feature, when people are concered
> > with cross machine consistency for the sake of caching and similar
> > build optimizations.
> >
> >
> > I still prefer #1.
> >
> >
> > 3) Or at least m3front/src/convert/Convert.m3
> > 3b) or ../../m3front/src/convert/Convert.m3
> >
> >
> > if we really want it to be a correct relative path from the target directory.
> >
> >
> > A big part of the problem is the build system is geared toward packages,
> > not multiple packages. I'd like to solve this problem too somehow someday.
> >
> >
> > Really -- #1 -- source paths should be full paths.
> >
> > C compilers vary here btw, in terms of what __FILE__ is and what is
> > in debugging information.
> > Sometimes whatever is passed on the command line is used.
> > Sometimes full paths are computed by the compiler.
> >
> >
> >   - Jay
> >
> >
> > _______________________________________________
> > M3devel mailing list
> > M3devel at elegosoft.com
> > https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> >
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150831/9e006a0c/attachment-0002.html>