Re: llvm issue

2018-02-24 Thread Jordon


I think you're on to something.  I just noticed that there is a 
clang++.core file that is 1,621,798,448 bytes.


I have never looked at the login.conf file (or really, that whole part 
of bsd) before.  What exactly am I going to change?  Under the 
'default:' section, I changed both datasize keys to 2048 (from 768) 
but it still fails.  Do you usually change some of the values from 
their defaults?


Thanks!
Jordon

Found it!  Under 'staff:' i changed datasize-cur from its 15xxM to 2048M 
and it builds now.  Thanks!


Jordon



Re: llvm issue

2018-02-24 Thread Jordon



On 02/24/2018 04:00 AM, Stuart Henderson wrote:

No crash here, but it does use 1.6GB during compile. Try raising memory
limits in login.conf (you'll need a new login session, which might mean
restarting X). Or try restricting with ulimit to see if you can trigger
the crash on other OS.

The SEGV is most likely to be due to a malloc without a return code check.



I think you're on to something.  I just noticed that there is a 
clang++.core file that is 1,621,798,448 bytes.


I have never looked at the login.conf file (or really, that whole part 
of bsd) before.  What exactly am I going to change?  Under the 
'default:' section, I changed both datasize keys to 2048 (from 768) but 
it still fails.  Do you usually change some of the values from their 
defaults?


Thanks!
Jordon



Re: llvm issue

2018-02-24 Thread Stuart Henderson
On 2018/02/23 17:21, Jordon wrote:
> I am running the latest snapshot (Feb 21) and discovered that some changes I
> made to my hobby project this evening make clang++ crash.  It builds find on
> linux with clang 3.8 and a High Sierra machine running whatever version
> Apple ships with that.

No crash here, but it does use 1.6GB during compile. Try raising memory
limits in login.conf (you'll need a new login session, which might mean
restarting X). Or try restricting with ulimit to see if you can trigger
the crash on other OS.

The SEGV is most likely to be due to a malloc without a return code check.



Re: llvm issue

2018-02-23 Thread Jordon

On 02/23/2018 05:21 PM, Jordon wrote:
I am running the latest snapshot (Feb 21) and discovered that some 
changes I made to my hobby project this evening make clang++ crash.  
It builds find on linux with clang 3.8 and a High Sierra machine 
running whatever version Apple ships with that.


The output message is this:

clang++  -Wall -fPIC -std=c++14 -c upgradedb.cpp
clang++: error: unable to execute command: Segmentation fault (core 
dumped)
clang++: error: clang frontend command failed due to signal (use -v to 
see invocation)
OpenBSD clang version 5.0.1 (tags/RELEASE_501/final) (based on LLVM 
5.0.1)

Target: amd64-unknown-openbsd6.2
Thread model: posix
InstalledDir: /usr/bin
clang++: note: diagnostic msg: PLEASE submit a bug report to 
http://llvm.org/bugs/ and include the crash backtrace, preprocessed 
source, and associated run script.

clang++: note: diagnostic msg:


PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++: note: diagnostic msg: /tmp/upgradedb-c3d6ce.cpp
clang++: note: diagnostic msg: /tmp/upgradedb-c3d6ce.sh
clang++: note: diagnostic msg:


*** Error 254 in /home/sirjorj/projects/xhud/libxwing (Makefile:32 
'upgradedb.o')



Is this an issue I should officially report with OpenBSD or is it an 
issue to take to LLVM


UPDATE: I set up a linux vm and put clang/llvm 5.0.1 on it and it built 
my program without any problems.


To reproduce the issue:
  clone this: https://github.com/sirjorj/libxwing
  run make to build it
  when it gets to upgradedb.cpp, it should crash clang++
  this source file initializes a std::vector<> of objects. today I 
added another element to the object and that seems to have pushed it 
over the edge.  i did notice that if you comment out a bunch of the 
items being initialized, it does build, so it looks like it is maybe a 
resource limitation.