This is the current git from yesterday, sys.c line 692 was one line from
return in a function that had to deal with DLL.
I ran it some more with different gdb options and found it appears to be in
LineEdit and jl_apply_generic with a few gf.c
Does Julia always spawn 4 threads?
On Monday, December 1, 2014 11:58:21 PM UTC-7, Jameson wrote:
>
> line 692 for me (on master) is the non-windows part of the function that
> you will arrive at upon typing a ^C in the REPL (jl_raise_debugger), so
> that seems quite sensible to me
>
> On Tue Dec 02 2014 at 1:35:31 AM Airhead Bit wrote:
>
> So much fun...
>> module sys.c line 692
>> Why is this application running code for _OS_WINDOWS_ on my ARM machine?
>> I got there by CTRL+C while running a debug julia, the majority locations
>> was 692
>> gdb -tui julia
>>
>>
>> On Friday, November 28, 2014 11:18:39 AM UTC-7, Airhead Bit wrote:
>>
>>> Just finished compiling one Error:
>>>
>>> Warning: error initializing module LinAlg:
>>>
>>> ErrorException("BLAS and LAPACK are compiled with 32-bit integer
>>> support, but Julia expects 64-bit integers. Please build Julia with
>>> USE_BLAS64=0.")
>>>
>>> exports.jl
>>>
>>>
>>> Julia works at the prompt but: TOP shows 400% CPU...
>>>
>>>
>>> root@radxa:~/julia# make testall
>>>
>>> JULIA test/all
>>>
>>> Master process (id 1) could not connect within 60.0 seconds.
>>>
>>> exiting.
>>>
>>> Master process (id 1) could not connect within 60.0 seconds.
>>>
>>> exiting.
>>>
>>> Master process (id 1) could not connect within 60.0 seconds.
>>>
>>> exiting.
>>>
>>> Worker 5 terminated.
>>>
>>> Worker 4 terminated.Worker 2 terminated.
>>>
>>>
>>> Eventually I was left with two Julia process's that each took 198.n%
>>> until I killed the terminal
>>>
>>> I'm going to build a clean system and build adding USE_BLAS64=0 in the
>>> Make.user file.
>>>
>>>
>>> Any other ideas for a build?
>>>
>>> Any ideas on how to tell what is sucking all the CPU?
>>>
>>>
>>>
>>>
>>>
>
