bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] svn 863 make warning/error


From: Alexey Veretennikov
Subject: Re: [Bug-apl] svn 863 make warning/error
Date: Thu, 02 Feb 2017 00:39:39 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (darwin)

Just in case, singletons are evil (and should be considered anti-pattern
in any app with more than 1 thread). Better to replace them with
external interfaces and use via dependency injection (it will help to
write more tests later).

Being there done that - moving all singleton::instance() to the main
function, still it is a short term solution, since in order to write
tests for the functions which uses your singletones you have to invent
special kind of mocks (it is possible but hard).

Juergen Sauermann <address@hidden> writes:

> Hi,
>
> I see, then it is probably gone since I reworked that area.
>
> BTW I have started to move all static object constructors to a single
> file, which gives more control over the construction order and avoids
> different orders with different compilers.
>
> /// Jürgen
>
> On 02/01/2017 08:17 PM, address@hidden wrote:
>
>  
> it was the get_name line you added in Id.cc 
>
> Core was generated by `/usr/local/apl-svn/bin/apl -v'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x08093b9b in std::basic_ios<char, std::char_traits<char> >::widen 
> (cond=0x8279234 "result", 
>     fun=0x824d573 "get_name", file=0x824d32e "Id.cc", line=85)
>     at 
> /usr/local/gcc/lib/gcc/i686-enztec-linux-gnu/4.4.3/../../../../include/c++/4.4.3/bits/basic_ios.h:440
> 440           { return __check_facet(_M_ctype).widen(__c); }
>
>
>
> On Wed, 1 Feb 2017 19:51:41 +0100
> Juergen Sauermann <address@hidden> wrote:
>
>  Hi,
>
> I wasn't able to decipher the core. It is difficult if the core was 
> dumped from a binary that differs
> from your own sources. It says:
>
> *...**
> **#9  0x082fba5c in VH_entry::history ()**
> **#10 0xbfb167b8 in ?? ()**
> **Backtrace stopped: previous frame inner to this frame (corrupt stack?)**
> **(gdb) **
> *
> It would be helpful if you could load the core into gdb on your system 
> and send me the
> backtrace displayed by gdb.
>
> I also fixed x⎕AV in *SVN 874* - I am getting too old for all of this.
>
> /// Jürgen
>
>
>
> On 02/01/2017 07:02 PM, address@hidden wrote:
>
>  
> Indeed you did
> btw you left the 'debug' x⎕AV in the Id.def    ;)
>
> here is the apl start  (i added the change in Symbol.cc to test and didn't 
> have to do the change in Id.def)
>
> name:                '⎕' at Symbol.cc:50
> name:                '⍞' at Symbol.cc:50
> name:                '⎕AI' at Symbol.cc:50
> name:                '⎕ARG' at Symbol.cc:50
> name:                'x⎕AV' at Symbol.cc:50
> name:                '⎕CT' at Symbol.cc:50
> name:                '⎕EM' at Symbol.cc:50
> name:                '⎕ET' at Symbol.cc:50
> name:                '⎕FC' at Symbol.cc:50
> name:                '⎕IO' at Symbol.cc:50
> name:                '⎕L' at Symbol.cc:50
> name:                '⎕LC' at Symbol.cc:50
> name:                '⎕LX' at Symbol.cc:50
> name:                '⎕PP' at Symbol.cc:50
> name:                '⎕PR' at Symbol.cc:50
> name:                '⎕PS' at Symbol.cc:50
> name:                '⎕PW' at Symbol.cc:50
> name:                '⎕R' at Symbol.cc:50
> name:                '⎕RL' at Symbol.cc:50
> name:                '⎕SVE' at Symbol.cc:50
> name:                '⎕SYL' at Symbol.cc:50
> name:                '⎕TC' at Symbol.cc:50
> name:                '⎕TS' at Symbol.cc:50
> name:                '⎕TZ' at Symbol.cc:50
> name:                '⎕UL' at Symbol.cc:50
> name:                '⎕X' at Symbol.cc:50
> name:                '⎕WA' at Symbol.cc:50
> name:                'λ' at Symbol.cc:50
> name:                '⍺' at Symbol.cc:50
> name:                '⍵' at Symbol.cc:50
> name:                'χ' at Symbol.cc:50
> name:                '⍶' at Symbol.cc:50
> name:                '⍹' at Symbol.cc:50
>
>
>        )wsid
> IS CLEAR WS
>        )save xyz
> 2017-02-01  10:51:46 (GMT-7)
>        )load xyz
> name:                '⎕CT' at Symbol.cc:50
> name:                '⎕FC' at Symbol.cc:50
> name:                '⎕IO' at Symbol.cc:50
> name:                '⎕L' at Symbol.cc:50
> name:                '⎕LX' at Symbol.cc:50
> name:                '⎕PP' at Symbol.cc:50
> name:                '⎕PR' at Symbol.cc:50
> name:                '⎕PS' at Symbol.cc:50
> name:                '⎕PW' at Symbol.cc:50
> name:                '⎕R' at Symbol.cc:50
> name:                '⎕RL' at Symbol.cc:50
> name:                '⎕SYL' at Symbol.cc:50
> name:                '⎕TZ' at Symbol.cc:50
> name:                '⎕X' at Symbol.cc:50
> name:                'λ' at Symbol.cc:50
> name:                '⍺' at Symbol.cc:50
> name:                '⍵' at Symbol.cc:50
> name:                'χ' at Symbol.cc:50
> name:                '⍶' at Symbol.cc:50
> name:                '⍹' at Symbol.cc:50
> SAVED 2017-02-01 10:51:46 (GMT-7)
>        )wsid
> IS xyz
>
> ---
>
> Post debrief
>
> was there a source code change step after the 'core dump' that you did to 
> figure this out ? or did you figure it out from the the core?
> I'd like to save this work as a case study type thing (it was a pretty 
> interesting set of circumstances)
>
> ---
>
> your progrmming talents are supreme - maybe you can take a look at my apl 
> code that causes my rasp pi running this 
> https://en.wikipedia.org/wiki/Digi-Comp_I to get stuck between floors of my 
> elevator ;)
> ^^ bad humour
>
> thanks  Jürgen   this was a great process to go through
> Ps I'll wait a few days to get back the the    ⍝ ∇   and    clear 
> screen/cursor location situation
>
> though here :
> /usr/bin/clear | hexdump -c    or -C for hex    -c gives ascii
> 0000000 033   [   H 033   [   2   J
> 0000007
>
> ====
>
> On Wed, 1 Feb 2017 13:07:27 +0100
> Juergen Sauermann <address@hidden> wrote:
>
>  Hi,
>
> I believe I found the problem.
>
> It looks like the constructor for the Workspace object (containing all system 
> variables)
> was called before the constructors for the system variables were called. That 
> made the
> names of the system variables empty strings.
>
> The compiler has some freedom regarding the order of initialization of static 
> objects
> and your compiler has chosen different order than mine.
>
> Hopefully fixed in SVN 872.
>
> /// Jürgen
>
>
> On 01/31/2017 11:47 PM, address@hidden wrote:
>
> core dump - i bz2'ed it and attached it
>
>
> On Tue, 31 Jan 2017 23:39:01 +0100
> Juergen Sauermann <address@hidden> wrote:
>
> Hi,
>
> sorry, should read:
>
> Q(ID::get_name(id))   // ← new line
>
> /// Jürgen
>
>
> On 01/31/2017 11:28 PM, address@hidden wrote:
> Q(name(ID::get_name(id)))   // ← new line
> Q(name.size())              // ← another new line
>   
>
>
>
>
>
>

-- 
Br,
/Alexey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]