Date: Mon, 22 Jul 1996 11:04:22 -0600 (MDT) From: Marc Slemko <marcs@valis.worldgate.com> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: bin/1411: vi dumps core when using 'set list' Message-ID: <Pine.BSI.3.94.960722093222.21203B-100000@valis.worldgate.com> In-Reply-To: <199607220558.HAA03774@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Jul 1996, J Wunsch wrote: > As Marc Slemko wrote: > > > After further investigation, this problem appears to be the result of > > using -m486 in the CFLAGS while compiling vi. If I compile without -m486, > > it works fine. > > That's strange. Jordan already mentioned that 2.1.5 was not compiled > with -m486, and i can add one more to this: everything i compile > (including the tests to reproduce the behaviour of your PR) _has_ the > -m486. Hmm. Well, I tried compiling it once again, this time with CFLAGS set to "-O2 -m486 -pipe" and the problem was not there. Trying with "-O2 -m486", the problem still wasn't there. With one of -O2 or -m486, it is still there. Hey, I just tried -m486 again and it won't show up. Grr. Try just using -O2 and see if you can make it show up. I just recompiled everything with "-O2"; the problem was there. I then removed common/svi_line.o and did another make, this time with no special CFLAGS. The problem went away. Removing common/svi_line.o once more and doing a make with CFLAGS set to -O2 brought the problem back. > So the question is now: you seem to be the only one who can > investigate this (since nobody else can reproduce it), are you > interested in tracking it further (e.g. core dump analysis), or do you > give up in which case we can do nothing but close the PR unresolved? I did a fresh 2.1.5 install this morning on a new box, completely different hardware. After I did the install, but before I had even rebooted (ie. in the shell on VT4), I could get vi to core dump in the same way. There isn't a whole lot that I could do before that time which would make much of a difference in the setup. I have repeated it on two different boxes with 2.1.5-RELEASE installed on them, two boxes with two entirely independent -stable source trees (both with -m486) with all binaries built locally, and another -stable box which was installed from one of the boxes with the stable source tree -stable on. If I were only able to reproduce the problem on locally compiled binaries, it could just be something messed up about how we are compiling. If I knew the problem was fixed (not just hidden, but known that it will not reappear) in current, it may not be worth bothering about. However, since I can reproduce it quite easily in both locally compiled binaries and 2.1.5-RELEASE... it may be worth bothering about. Since I do seem to be saying some conflicting things, if you still can't reproduce it give me a week or so to at least straighten out my story and see what else I can find. At this point, it is really looking like a gcc bug. If it is a gcc bug, the next logical step would be to compare the assembly output from gcc using various options; unfortunately, that's a bit beyond what I am capable of understanding, especially since the problem is in optimizations.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.960722093222.21203B-100000>