[developers] ACE on Ubuntu on Windows
goodman.m.w at gmail.com
goodman.m.w at gmail.com
Sat Sep 1 03:02:08 CEST 2018
Thanks for the analysis, Dan. I also found that these nested functions are
a feature specific to GCC (here's a nice explanation:
https://stackoverflow.com/a/8179587/1441112). I tried to count how many of
these there are in the ACE code (e.g., assuming they are function
signatures that are indented), and I came up with 50 (see the attached
file). I think some would be trivial to replace, but when they are passed
as arguments it might be more complicated.
On Wed, Aug 22, 2018 at 3:58 PM Dan Flickinger <danf at stanford.edu> wrote:
> Hi Woodley and Guy,
>
>
> Following up on Bianca's and Guy's recent exchange, I did a little more
> experimenting with WSL and ACE, and it seems that Woodley was right two
> years ago to suspect those inner functions being uncooperative in WSL. I
> compiled ACE from source in an Ubuntu version of WSL, and then tried
> compiling the ERG. I got a segmentation fault which I tracked down (as Guy
> had done) to the function load_preprocessor, which defines an inner
> function and then calls iterate_conf_list with a pointer to that function
> as its second argument. But iterate_conf_list fails when it tries to
> execute that function in the line "if(callback(p)...". I also tried
> commenting out that line, recompiling ACE, and then recompiling the ERG,
> and indeed, it gets almost all the way through before hitting a seg fault
> right after compiling the lexicon.
>
>
> Here is a relevant thread I found about the issue in WSL:
>
> https://github.com/Microsoft/WSL/issues/3083
>
>
> My impression from that discussion is that the WSL folks believe enabling
> an executable stack would be a security hole and hence won't support it.
> So if my reading is right, perhaps there is no hope of getting ACE to run
> on WSL, since as Woodley notes, these inner functions get used and passed
> as arguments in lots of places in the ACE code. But it would be useful if
> Woodley could either confirm this apparent incompatibility so we can give
> up on WSL, or suggest a workaround if one is readily available.
>
> Dan
>
>
> ------------------------------
> *From:* developers-bounces at emmtee.net <developers-bounces at emmtee.net> on
> behalf of Woodley Packard <sweaglesw at sweaglesw.org>
> *Sent:* Thursday, November 17, 2016 10:40 AM
> *To:* Guy Emerson
> *Cc:* developers
> *Subject:* Re: [developers] ACE on Ubuntu on Windows
>
> The only thing I notice about both of those crash contexts is that they
> likely involve inner functions, a GCC extension whose implementation
> requires an executable stack. Some operating systems make the stack
> non-executable. There may be a way of setting an option, if this is indeed
> the problem. I would have thought it would have crashed earlier than
> lexical lookup, though, because I make extensive use of them.
>
> Woodley
>
>
>
> On Nov 17, 2016, at 1:26 AM, Guy Emerson <gete2 at cam.ac.uk> wrote:
>
> If I do that, it successfully builds. I still get a segfault when trying
> to compile the ERG:
>
> reading configuration from `../erg/trunk/ace/config.tdl'
> reading types from `../erg/trunk/ace/../mtr.tdl'
> grammar version ERG (trunk)
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff121f688 in ?? ()
> (gdb) backtrace
> #0 0x00007ffff121f688 in ?? ()
> #1 0x00000000004d7909 in iterate_conf_list (key=key at entry=0x5bc11a
> "preprocessor-modules", callback=callback at entry=0x7ffff121f688) at
> conf.c:534
> #2 0x00000000004d9fe1 in load_preprocessor () at preprocessor.c:58
> #3 0x0000000000471f80 in load_grammar (path=<optimized out>) at tdl.c:1660
> #4 0x000000000052aece in initialize_engine () at main.c:523
> #5 0x000000000045a47a in main (argc=5, argv=0x7ffff121fa88) at main.c:620
>
>
> Or when using the pre-compiled grammar:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fffccdfc110 in ?? ()
> (gdb) backtrace
> #0 0x00007fffccdfc110 in ?? ()
> #1 0x000000000045ad8d in visit_lexicon (stem=<optimized out>,
> visitor=visitor at entry=0x7fffccdfc110) at lexicon.c:137
> #2 0x0000000000481f78 in lexical_lookup (tc=tc at entry=0x7f09e27d0000) at
> morpho.c:283
> #3 0x00000000004eb2ba in lexical_lookup_into_chart
> (token_chart=token_chart at entry=0x7f09e27d0000) at lexical-parse.c:64
> #4 0x00000000004ca8f4 in parse_with_token_chart
> (token_chart=0x7f09e27d0000, start=start at entry=31250) at parse.c:481
> #5 0x00000000004cd9a1 in parse (sentence=0x806b40 <current_sentence>
> "Hello", cto=0x1216100, cfrom=0x12160e0, words=0x12160c0, nwords=1) at
> parse.c:449
> #6 parse_line1 (line=<optimized out>, line at entry=0x7fffccdfeb60 "Hello")
> at parse.c:743
> #7 0x00000000004cdb56 in parse_line (line=line at entry=0x7fffccdfeb60
> "Hello") at parse.c:768
> #8 0x000000000052ab79 in main_input_loop (fin=0x7f09e308f640
> <_IO_2_1_stdin_>) at main.c:443
> #9 0x000000000045a4fa in main (argc=4, argv=0x7fffcce014e8) at main.c:653
>
>
> If it's not clear why these lines could cause a segfault, I will assume
> there is a problem with the Windows Subsystem for Linux (it's still
> labelled "beta", after all), and I'll try again in a few months.
>
>
> 2016-11-16 22:23 GMT+00:00 Woodley Packard <sweaglesw at sweaglesw.org>:
>
> Hi Guy,
>
> You are on the right track with the two lines in the makefile commented
> out.
>
> Something has perhaps changed since it has been built in that mode. Try
> adding this to the top of itsdb.c:
>
> #define capi_printf printf
>
> and running "make" again?
> Woodley
>
>
>
> On Nov 16, 2016, at 8:47 AM, Guy Emerson <gete2 at cam.ac.uk> wrote:
>
> I used the precompiled binary and grammar - I didn't realise that librepp
> was only for compiling from source.
>
> Running gdb, I get:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fffdec22300 in ?? ()
> (gdb) backtrace
> #0 0x00007fffdec22300 in ?? ()
> #1 0x000000000046290a in visit_lexicon (stem=<optimized out>,
> visitor=0x7fffdec22300) at lexicon.c:137
> #2 0x00000000004845fc in lexical_lookup (tc=0x7f27168d0000) at
> morpho.c:283
> #3 0x00000000004df9b1 in lexical_lookup_into_chart
> (token_chart=0x7f27168d0000) at lexical-parse.c:64
> #4 0x00000000004c0ff8 in parse_with_token_chart
> (token_chart=0x7f27168d0000, start=46875) at parse.c:481
> #5 0x00000000004c37e1 in parse_line1 (line=0x7fffdec22540 "Hello") at
> parse.c:743
> #6 0x00000000004c3936 in parse_line (line=0x6005692cfc ",-i\005`") at
> parse.c:768
> #7 0x0000000000516677 in main_input_loop (fin=0x7f271708f640
> <_IO_2_1_stdin_>) at main.c:443
> #8 0x0000000000517561 in main (argc=4, argv=0x7fffdec276c8) at main.c:653
>
>
> If I try to compile the ERG image (using the precompiled binary), I also
> get a seg fault:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007fffcea82cd8 in ?? ()
> (gdb) backtrace
> #0 0x00007fffcea82cd8 in ?? ()
> #1 0x00000000004ccfbe in iterate_conf_list (key=<optimized out>,
> callback=0x7fffcea82cd8) at conf.c:534
> #2 0x00000000004ce9aa in load_preprocessor () at preprocessor.c:58
> #3 0x0000000000472772 in load_grammar (path=0x7fffcea831fc
> "/home/Guy/delphin/erg/trunk/ace/config.tdl") at tdl.c:1660
> #4 0x0000000000515dbe in initialize_engine () at main.c:523
> #5 0x000000000051735d in main (argc=6, argv=0x7fffcea82fb8) at main.c:620
>
>
> If I try to compile ACE from source, without any changes, there is an
> error that itsdb.h is not found.
>
> If I try to compile ACE after commenting out the two lines in the Makefile
> for itsdb, there is an error that capi_printf is not defined in itsdb.o.
>
> If I also remove itsdb.o from the Makefile, many things are undefined.
>
>
>
> As I'm not a C developer, I have very little sense about how easy this
> would be to debug or to fix... I'm quite happy to be told this is not
> worth the effort!
>
>
>
> 2016-11-15 17:12 GMT+00:00 Woodley Packard <sweaglesw at sweaglesw.org>:
>
> Out of curiousity, Guy, were you able to use the precompiled binary for
> ACE or did you have to compile your own? I wouldn’t have thought you would
> need to install the librepp and boost dependencies if using the binaries.
> It looks like you are using the precompiled ERG image though. You could be
> getting a crash if you are using a stock 0.9.24 grammar image with SVN
> trunk ACE source code. On the off chance that you are doing that, please
> try compiling the ERG image with the same ACE binary you are using. It
> *might* be helpful to recompile the ERG image anyway.
>
> Regards,
> -Woodley
>
> > On Nov 15, 2016, at 6:33 AM, Guy Emerson <gete2 at cam.ac.uk> wrote:
> >
> > I am trying to run ACE on Windows 10's new Linux Subsystem. I can run
> ACE with the ERG, but whatever input I give, I get the message "ERROR:
> DEADLY SIGNAL!"
> >
> > It looks like it finishes the token mapping, and fails when applying a
> syntactic rule. Verbose output is below.
> >
> > I've already installed repp-0.2.2 (which required me to also install
> libboost), and I've set the TMPDIR environment variable, as suggested on
> the ACE homepage.
> >
> > Any ideas on what else I would need to do? Could there be other
> dependencies I need to install?
> >
> > Best,
> > Guy
> >
> >
> >
> > ./ace -g erg-1214-x86-64-0.9.24.dat -1Tf -vvv
> > NOTE: loading frozen grammar ERG (1214)
> > NOTE: semantic index hash contains 28857 entries in 65536 slots
> > NOTE: max-ent model hash contains 659414 entries in 1048576 slots
> > NOTE: 9280 types, 38259 lexemes, 293 rules, 47 orules, 101 instances,
> 48101 strings, 216 features
> > permanent RAM: 4k
> >
> > Hello
> > Hello/UH
> > token #12 le 0x7f07295d7fcc vtx [0-1] char [0-5] string 'hello' dag
> #D[token +FORM: #D["hello"] +FROM: <1>= #D["0"] +TO: #D["5"] +ID:
> #D[*diff-list* LIST: #D[*list*] LAST: #D[*list*] ] +TNT: #D[null_tnt +TAGS:
> #D[*null*] +PRBS: #D[*null*] +MAIN: #D[tnt_main +TAG: #D["UH"] +PRB:
> #D["1.0"] ] ] +CLASS: #D[alphabetic +INITIAL: #D[+] +CASE:
> #D[capitalized+lower] ] +TRAIT: #D[token_trait +UW: #D[-] +IT: #D[italics]
> +LB: #D[bracket_null] +RB: #D[bracket_null] +HD: #D[token_head +LL:
> #D[ctype -CTYPE-: #D[string] ] +TG: #D[string] +TI: <1> ] ] +PRED:
> #D[predsort] +CARG: #D["Hello"] +TICK: #D[bool] ]
> > token #13 le 0x7f07295d87e0 vtx [0-1] char [0-5] string 'hello' dag
> #D[token +FORM: #D["hello"] +FROM: <1>= #D["0"] +TO: #D["5"] +ID:
> #D[*diff-list* LIST: #D[*list*] LAST: #D[*list*] ] +TNT: #D[null_tnt +TAGS:
> #D[*null*] +PRBS: #D[*null*] +MAIN: #D[tnt_main +TAG: #D[string] +PRB:
> #D[string] ] ] +CLASS: #D[bridge_class] +TRAIT: #D[token_trait +UW: #D[+]
> +IT: #D[italics] +LB: #D[bracket_null] +RB: #D[bracket_null] +HD:
> #D[token_head +LL: #D[ctype -CTYPE-: #D[string] ] +TG: #D[string] +TI: <1>
> ] ] +PRED: #D["_hello_u_bridge_rel"] +CARG: #D["Hello"] +TICK: #D[bool] ]
> > finished token mapping
> > hello -> hello [2 ways]
> >
> > non_third_sg_fin_v_rbst
> > hello -> hello [2 ways]
> >
> > non_third_sg_fin_v_rbst
> > ERROR: DEADLY SIGNAL! sent = `Hello'
>
>
>
>
--
-Michael Wayne Goodman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20180831/4bdcc865/attachment-0001.html>
-------------- next part --------------
void got_edge(struct tree *tx, struct dg *d)
int show_result(struct hypothesis *hyp, struct mrs *mrs_res, double prob)
char *freeze_string(char *S)
void lex_edge_adder(struct edge *le)
void agendize_edge(struct edge *e)
void lex_edge_adder(struct edge *le)
int capi_print_tree(struct hypothesis *hyp, struct mrs *mrs, double prob)
int callback(char *name, struct dg *dg, struct tdl_line *tdl)
void edge_handler(struct edge *le, struct token **tokens)
void my_callback(struct hypothesis *h, struct mrs *m)
void lui_print_chart_edge(struct edge *e)
void output_lui_mrs_var(struct mrs_var *v)
void imrs_var(struct mrs_var *v)
int iter(struct hypothesis *hyp, struct mrs *mrs, double prob)
int show_tree(struct hypothesis *hyp, struct mrs *mrs)
void lui_print_chart_edge(struct edge *e)
void quitme(int sig) { done = 1; }
void visitor(struct maxent_feature *feat)
int mwe_lex_handler(struct lexeme *lex, struct lattice_edge *mwe_lat_e, int pos)
int lex_handler(struct lexeme *lex)
void visit_irreg_stem(char *stem)
int callback(char *path)
void parse_trigger(struct mrs_vlist *v, char **P, char **T) { *T = strdup(parse_word(P, 1)); }
int orth_route_cmp(const struct orth_route *ra, const struct orth_route *rb)
void save_generalization_candidate(struct edge *c)
int repp_module_callback(char *path) {
int pcmp(const struct profiler **a, const struct profiler **b)
int lexcmp(const struct qc_path *a, const struct qc_path *b)
int qcpcmp(const struct qc_path *a, const struct qc_path *b) { return b->failures - a->failures; }
void record_mark(int mark, int d, int s)
void tsort(struct type *t)
int rule_does_not_exist(char *name)
int build_rule_filter_transitive_closure()
int build_type_rule_filter()
int compose_type_rule_closured_filter()
void add_anc(struct type *t, unsigned long long *v)
void add_dec(struct type *t, unsigned long long *v)
void add_vac(char *lexid, struct dg *cons)
int do_load_mem() { load_mem(get_conf_file_path("maxent-model")); return 0; }
void traverse(struct lattice_vertex *v)
int unify_vars(struct mrs_var *vin, struct mrs_var *vrule)
int filtercb(int *filtalign, int *filthcalign) { did_filter = 1; return 1; } // return of 1 indicates we don't care about more alignments; one is enough to say it was filtered.
int found_alignment(int *alignment, int *hcalignment)
int found_alignment(int *alignment, int *hcalignment)
int found_alignment(int *alignment, int *hcalignment)
int ecmp(const struct ut_emission *a, const struct ut_emission *b)
int epcmp(const struct ut_emission **a, const struct ut_emission **b)
void print_tree0(struct hypothesis *hyp, int from, char **genwordforms)
int dprintf(const char *fmt, ...)
int dprintf(const char *fmt, ...)
More information about the developers
mailing list