From: Daniel F. <fly...@go...> - 2010-09-16 23:50:16
|
Where there any changes on the yaws_cgi:call_cgi method since yaws 1.87? had a trayout with the code from git and my 404 error module only produced an error now. Code: -module(arbit_404_handler). -author('fly...@go...'). -include("yaws/include/yaws.hrl"). -include("yaws/include/yaws_api.hrl"). -export([out404/1, out404/3, crashmsg/3]). out404(Arg) -> out404(Arg, get(gc), get(sc)). out404(Arg, GC, SC) -> yaws_cgi:call_cgi(Arg, GC#gconf.phpexe, lists:flatten(Arg#arg.docroot) ++ "/index.php"). crashmsg(_Arg, _SC, L) -> {ehtml, [{h2, [], "Internal error, yaws code crashed"}, {br}, {hr}, {pre, [], L}, {hr}]}. This produce the following error ERROR erlang code crashed: File: 404:0 Reason: {{badrecord,gconf}, [{arbit_404_handler,out404,3}, {yaws_server,deliver_dyn_part,8}, {yaws_server,aloop,3}, {yaws_server,acceptor0,2}, {proc_lib,init_p_do_apply,3}]} Req: {http_request,'GET',{abs_path,"/test"},{1,1}} Stack: [{arbit_404_handler,out404,3}, {yaws_server,deliver_dyn_part,8}, {yaws_server,aloop,3}, {yaws_server,acceptor0,2}, {proc_lib,init_p_do_apply,3}] I dont find the cause for this error and with the 1.87 release there is no problem. Any Ideas? |
From: Steve V. <vi...@ie...> - 2010-09-17 01:15:32
|
On Thu, Sep 16, 2010 at 7:50 PM, Daniel Fahlke <fly...@go...> wrote: > Where there any changes on the yaws_cgi:call_cgi method since yaws 1.87? Not that I can see, but it doesn't matter because according to your stacktrace you're not even getting there. > had a trayout with the code from git and my 404 error module only produced > an error now. > > out404(Arg) -> > out404(Arg, get(gc), get(sc)). > out404(Arg, GC, SC) -> > yaws_cgi:call_cgi(Arg, GC#gconf.phpexe, lists:flatten(Arg#arg.docroot) > ++ "/index.php"). Hmm, are we sure get(gc) is returning a gconf record? You can get this error if GC is a term other than a gconf record. Do this: 1. Run yaws with -i or --interactive. 2. At the erlang shell prompt, type dbg:tracer(), dbg:p(all, call). 3. Then type dbg:tp(arbit_404_handler, out404, dbg:fun2ms(fun([_, GC, _]) -> message(GC) end)). 4. Run the test that causes the crash. 5. Check the dbg output to see what the GC value was. If the GC variable isn't a gconf record, then there's likely a bug in yaws. In that case if you can trim your code down to a testcase you can submit here, that would be great. --steve |
From: Daniel F. <fly...@go...> - 2010-09-17 12:31:39
|
Have tried it with old and new yaws version. first yaws from trunk: (<0.65.0>) call arbit_404_handler:out404({arg,#Port<0.1035>, {{78,52,98,95},33314}, {headers,"keep-alive", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "arbit.dev.manaworld.de",undefined,undefined,undefined, undefined,undefined,undefined,"http://arbit.dev.manaworld.de/ ", "Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.10pre) Gecko/20100915 Ubuntu/9.10 (karmic) Namoroka/3.6.10pre", undefined, ["__utma=75807753.1628536033.1208206305.1283644725.1283646911.111; __utmz=75807753.1269845925.91.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); PHPSESSID=8TEREqYE0Gb-uOALnNMav3"], "115",undefined,undefined,undefined,undefined,undefined, undefined, [{http_header,1,'Cache-Control',undefined,"max-age=0"}, {http_header,9,'Accept-Charset',undefined, "ISO-8859-1,utf-8;q=0.7,*;q=0.7"}, {http_header,10,'Accept-Encoding',undefined,"gzip,deflate"}, {http_header,11,'Accept-Language',undefined, "de,en-us;q=0.7,en;q=0.3"}]}, {http_request,'GET',{abs_path,"/map_editor"},{1,1}}, undefined,"/map_editor",undefined,undefined, "/var/www/elenear_arbit/htdocs","/",[],undefined,undefined,<0.65.0>,[], undefined,[],undefined},{gconf,"/usr/local/lib/yaws",false,207,"/var/log/yaws", ["/var/yaws/ebin","/usr/local/lib/yaws/examples/ebin", "/usr/local/lib/yaws/examples/ebin"], [],30000,nolimit,400,1000000,8000,nolimit,[],10240,[],50000000,0, ["/usr/local/lib/yaws/examples/include", "/usr/local/lib/yaws/examples/include"], "/usr/bin/php-cgi","Yaws 1.88","default",false,[]},{sconf,80,2,[],undefined,undefined,"/var/www/elenear_arbit/htdocs",[], {85,214,102,119}, "arbit.dev.manaworld.de",24594,undefined,[],10240,[],yaws_outmod, arbit_404_handler,yaws_outmod,yaws,[],undefined, [php], [],[],[],[],undefined,undefined,undefined}) ({gconf, "/usr/local/lib/yaws", false,207, "/var/log/yaws", ["/var/yaws/ebin", "/usr/local/lib/yaws/examples/ebin", "/usr/local/lib/yaws/examples/ebin"], [],30000,nolimit,400, 1000000,8000,nolimit,[], 10240,[],50000000,0, ["/usr/local/lib/yaws/examples/include", "/usr/local/lib/yaws/examples/include"], "/usr/bin/php-cgi", "Yaws 1.88","default", false,[]}) =ERROR REPORT==== 17-Sep-2010::13:51:38 === now the output with previous yaws version (<0.50.0>) call arbit_404_handler:out404({arg,#Port<0.899>, {{78,52,98,95},33979}, {headers,"keep-alive", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8", "arbit.dev.manaworld.de",undefined,undefined,undefined, undefined,undefined,undefined,"http://arbit.dev.manaworld.de/ ", "Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.10pre) Gecko/20100915 Ubuntu/9.10 (karmic) Namoroka/3.6.10pre", undefined, ["__utma=75807753.1628536033.1208206305.1283644725.1283646911.111; __utmz=75807753.1269845925.91.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); PHPSESSID=8TEREqYE0Gb-uOALnNMav3"], "115",undefined,undefined,undefined,undefined,undefined, undefined, [{http_header,1,'Cache-Control',undefined,"max-age=0"}, {http_header,9,'Accept-Charset',undefined, "ISO-8859-1,utf-8;q=0.7,*;q=0.7"}, {http_header,10,'Accept-Encoding',undefined,"gzip,deflate"}, {http_header,11,'Accept-Language',undefined, "de,en-us;q=0.7,en;q=0.3"}]}, {http_request,'GET',{abs_path,"/map_editor"},{1,1}}, undefined,"/map_editor",undefined,undefined, "/var/www/elenear_arbit/htdocs","/",[],undefined,undefined,<0.50.0>,[], undefined,[],undefined},{gconf,"/usr/local/lib/yaws",false,207,"/var/log/yaws", ["/var/yaws/ebin","/usr/local/lib/yaws/examples/ebin", "/usr/local/lib/yaws/examples/ebin"], [],30000,400,1000000,8000,nolimit,10240,[],50000000,0, ["/usr/local/lib/yaws/examples/include", "/usr/local/lib/yaws/examples/include"], "/usr/bin/php-cgi","Yaws 1.87","default",false,[]},{sconf,80,2,[],undefined,undefined,"/var/www/elenear_arbit/htdocs",[], {85,214,102,119}, "arbit.dev.manaworld.de",24591,undefined,[],nolimit,[],yaws_outmod, arbit_404_handler,yaws_outmod,yaws,[],undefined, [php], [],[],[],[],undefined,undefined,undefined}) ({gconf, "/usr/local/lib/yaws", false,207, "/var/log/yaws", ["/var/yaws/ebin", "/usr/local/lib/yaws/examples/ebin", "/usr/local/lib/yaws/examples/ebin"], [],30000,400,1000000, 8000,nolimit,10240,[], 50000000,0, ["/usr/local/lib/yaws/examples/include", "/usr/local/lib/yaws/examples/include"], "/usr/bin/php-cgi", "Yaws 1.87","default", false,[]}) I think you will better see if the problem comes from there 2010/9/17 Steve Vinoski <vi...@ie...> > On Thu, Sep 16, 2010 at 7:50 PM, Daniel Fahlke > <fly...@go...> wrote: > > Where there any changes on the yaws_cgi:call_cgi method since yaws 1.87? > > Not that I can see, but it doesn't matter because according to your > stacktrace you're not even getting there. > > > had a trayout with the code from git and my 404 error module only > produced > > an error now. > > > > out404(Arg) -> > > out404(Arg, get(gc), get(sc)). > > out404(Arg, GC, SC) -> > > yaws_cgi:call_cgi(Arg, GC#gconf.phpexe, > lists:flatten(Arg#arg.docroot) > > ++ "/index.php"). > > Hmm, are we sure get(gc) is returning a gconf record? You can get this > error if GC is a term other than a gconf record. Do this: > > 1. Run yaws with -i or --interactive. > > 2. At the erlang shell prompt, type > > dbg:tracer(), dbg:p(all, call). > > 3. Then type > > dbg:tp(arbit_404_handler, out404, dbg:fun2ms(fun([_, GC, _]) -> > message(GC) end)). > > 4. Run the test that causes the crash. > > 5. Check the dbg output to see what the GC value was. > > If the GC variable isn't a gconf record, then there's likely a bug in > yaws. In that case if you can trim your code down to a testcase you > can submit here, that would be great. > > --steve > |
From: Mojito S. <moj...@gm...> - 2010-09-17 13:39:31
|
In the very short chapter on Embedded Mode, the YAWS pdf file says "The YAWS source tree must be integrated into the larger applications build environment. " I am not clear on what that means. Is there a worked example somewhere? |
From: Claes W. <kl...@ta...> - 2010-09-17 19:24:28
|
On 09/17/2010 03:39 PM, Mojito Sorbet wrote: > In the very short chapter on Embedded Mode, the YAWS pdf file says "The > YAWS source tree must be integrated into the larger applications build > environment. " I am not clear on what that means. Is there a worked > example somewhere? > This is false, you don't have to do that, you can run embedded mode without recompiling yaws in your own project. /klacke |
From: Steve V. <vi...@ie...> - 2010-09-17 14:19:52
|
On Fri, Sep 17, 2010 at 8:31 AM, Daniel Fahlke <fly...@go...> wrote: > Have tried it with old and new yaws version. <snip/> Question: did you recompile your arbit_404_handler module against the newer version of yaws before running it there? If not, try that. There are changes in the gconf record between the versions. --steve |
From: Daniel F. <fly...@go...> - 2010-09-17 15:10:33
|
Have recompiled it now(have it done before, but not for produce the debug output) What i think is interesting, if i compile the module with the new version and than install the old, there is no error. Could it be possible, that i use the wrong path? anyway i looked at the end of the install output and found a difference. at old install: sh ./Install /usr/local "/usr/bin/erl" \ "" /etc/ /var/ /usr/lib/erlang/bin/ at new install: sh ./Install /usr/local "/usr/local/bin/erl" \ "" /etc/ /var/ /usr/local/lib/erlang/bin/ but the paths are all the same ** etc files went into /etc ** executables went into /usr/local/bin ** library files went into /usr/local/lib/yaws ** var files went into /var ** default docroot went into /var/yaws/www /usr/bin/erl is i think the installation from the dist /usr/bin/erl --version Erlang (BEAM) emulator version 5.6.5 [source] [smp:2] [async-threads:0] [kernel-poll:false] /usr/local/bin/erl is the one, i compiled myself some time ago /usr/local/bin/erl --version Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] [hipe] [kernel-poll:false] why is there a difference? i think i compiled erlang after i installed yaws, so the configure script had the old paths. For testing i rund the configure script to renew the paths and yes, now both versions use the same paths at this point. But there is no difference. Old yaws run fine, new does not. 2010/9/17 Steve Vinoski <vi...@ie...> > On Fri, Sep 17, 2010 at 8:31 AM, Daniel Fahlke > <fly...@go...> wrote: > > Have tried it with old and new yaws version. > > <snip/> > > Question: did you recompile your arbit_404_handler module against the > newer version of yaws before running it there? If not, try that. There > are changes in the gconf record between the versions. > > --steve > |
From: Daniel F. <fly...@go...> - 2010-09-17 18:03:37
|
had played a little with 404 error module. now i know that GC#gconf.phpexe produce the error. So, how do i get the php exe path? 2010/9/17 Daniel Fahlke <fly...@go...> > Have recompiled it now(have it done before, but not for produce the debug > output) > > What i think is interesting, if i compile the module with the new version > and than install the old, there is no error. > Could it be possible, that i use the wrong path? > > anyway i looked at the end of the install output and found a difference. > > at old install: > sh ./Install /usr/local "/usr/bin/erl" \ > "" /etc/ /var/ /usr/lib/erlang/bin/ > at new install: > sh ./Install /usr/local "/usr/local/bin/erl" \ > "" /etc/ /var/ /usr/local/lib/erlang/bin/ > > but the paths are all the same > > ** etc files went into /etc > ** executables went into /usr/local/bin > ** library files went into /usr/local/lib/yaws > ** var files went into /var > ** default docroot went into /var/yaws/www > > > /usr/bin/erl is i think the installation from the dist > /usr/bin/erl --version > Erlang (BEAM) emulator version 5.6.5 [source] [smp:2] [async-threads:0] > [kernel-poll:false] > > /usr/local/bin/erl is the one, i compiled myself some time ago > /usr/local/bin/erl --version > Erlang R13B03 (erts-5.7.4) [source] [smp:2:2] [rq:2] [async-threads:0] > [hipe] [kernel-poll:false] > > > why is there a difference? i think i compiled erlang after i installed > yaws, so the configure script had the old paths. > For testing i rund the configure script to renew the paths and yes, now > both versions use the same paths at this point. > But there is no difference. Old yaws run fine, new does not. > > 2010/9/17 Steve Vinoski <vi...@ie...> > >> On Fri, Sep 17, 2010 at 8:31 AM, Daniel Fahlke >> >> <fly...@go...> wrote: >> > Have tried it with old and new yaws version. >> >> <snip/> >> >> Question: did you recompile your arbit_404_handler module against the >> newer version of yaws before running it there? If not, try that. There >> are changes in the gconf record between the versions. >> >> --steve >> > > |
From: Steve V. <vi...@ie...> - 2010-09-19 20:27:30
|
On Fri, Sep 17, 2010 at 2:03 PM, Daniel Fahlke <fly...@go...> wrote: > had played a little with 404 error module. > > now i know that GC#gconf.phpexe produce the error. > > So, how do i get the php exe path? Are you asking whether the phpexe field of the record is still viable? If so, the answer is yes, that's the way you get the pathname of the php executable. I still think you're mixing modules compiled against different versions of yaws. The badrecord exception is due either to changing the record definition for some modules but not others and passing records between them, or due to passing something other than a record as an argument where a record is expected and used. We've already proven via tracing that the record is being passed correctly, so that leaves the compilation problem as the likely culprit. --steve --steve --steve |