artanis
[Top][All Lists]
Advanced

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

Re: Error From "art work" on Vanilla Artanis Project


From: Nala Ginrut
Subject: Re: Error From "art work" on Vanilla Artanis Project
Date: Mon, 24 Feb 2020 11:06:19 +0800
User-agent: mu4e 1.3.5; emacs 26.1

Thanks for the info!
I'll see what I can do. For now, if you want to continue your Artanis
adventure, I think you can modify server.engine from `ragnarok' to
`guile'. Or just run `art work -s guile'

Best regards.

Jaft writes:

>  Ohhh; I gotcha now. When I'd said that, that was before we realized that 
> this seems Raspberry Pi specific.
> I'd been using Artanis on my local laptop and with Heroku and it was working 
> there but I haven't been able to get it working on the Raspberry Pi, at all.
> I was curious so I updated the version on my laptop to the latest Artanis to 
> compare against the Pi and it still worked on my laptop.
> So there was no commit that worked with the Pi (to my knowledge), I'm afraid.
> Jonathan    On Sunday, February 23, 2020, 10:55:19 AM CST, Nala Ginrut 
> <address@hidden> wrote:
>
>
> No, I'm not doubting you're using the wrong commit.
> According to your description, Artanis worked before you upgrade to the
> vanilla code. So do you still remember the workable commit number?
>
> Best regards.
>
> Jaft writes:
>
>>  That I built Artanis from for the Raspbian and Ubuntu tries? Just the 
>> latest commit from the fix/epoll-exists-check branch: fix (7cd747d7) · 
>> Commits · Nala Ginrut / artanis.
>> Jonathan
>>
>> |
>> |
>> |
>> |  |  |
>>
>>  |
>>
>>  |
>> |
>> |  |
>> fix (7cd747d7) · Commits · Nala Ginrut / artanis
>>
>> A fast monolithic framework of Scheme language
>>  |
>>
>>  |
>>
>>  |
>>
>>
>>
>>
>>    On Sunday, February 23, 2020, 2:32:49 AM CST, Nala Ginrut 
>> <address@hidden> wrote:
>>
>>
>> BTW, could you tell me the git commit number before you upgrade?
>>
>> Jaft writes:
>>
>>>  Alright; and here's the output of lscpu for Ubuntu on the same Raspberry 
>>> Pi:
>>> Architecture:        aarch64Byte Order:          Little EndianCPU(s):       
>>>        4On-line CPU(s) list: 0-3Thread(s) per core:  1Core(s) per socket:  
>>> 4Socket(s):          1Vendor ID:          ARMModel:              3Model 
>>> name:          Cortex-A72Stepping:            r0p3CPU max MHz:        
>>> 1500.0000CPU min MHz:        600.0000BogoMIPS:            108.00Flags:      
>>>         fp asimd evtstrm crc32 cpuid
>>> And with the logs from the same branch as before attached; unfortunately, 
>>> it looked like the same error.
>>> Jonathan    On Saturday, February 22, 2020, 3:11:50 PM CST, Jaft 
>>> <address@hidden> wrote:
>>>
>>>  Sure thing, Nala. Here's the entire output of lscpu for Raspbian:
>>> Architecture:        armv7lByte Order:          Little EndianCPU(s):        
>>>       4On-line CPU(s) list: 0-3Thread(s) per core:  1Core(s) per socket:  
>>> 4Socket(s):          1Vendor ID:          ARMModel:              3Model 
>>> name:          Cortex-A72Stepping:            r0p3CPU max MHz:        
>>> 1500.0000CPU min MHz:        600.0000BogoMIPS:            108.00Flags:      
>>>         half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt 
>>> vfpd32 lpae evtstrm crc32
>>> I'm gonna attempt to install Ubuntu, now, and see what happens.
>>> Jonathan    On Saturday, February 22, 2020, 3:38:39 AM CST, Nala Ginrut 
>>> <address@hidden> wrote:
>>>
>>>
>>> BTW, please use `lscpu' the check if the endianess is little endian. I
>>> think most of ARM system use little by default. And the epoll of Artanis
>>> does assume it's little endian which should be fixed in the future.
>>>
>>> Best regards.
>>>
>>> Jaft writes:
>>>
>>>> Of course! I'd wanted to be able to web development with Guile for the 
>>>> longest time and was delighted when I found Artanis; I'm happy to help in 
>>>> whatever way I can.
>>>> I don't have a separate ARM device but I could write a different distro to 
>>>> my microSD and try that on the same Pi?
>>>> Would Ubuntu be alright to try next? I'm most familiar with debian-based 
>>>> ones (so others might take me longer to get everything setup, again) but, 
>>>> given the two are related, I could understand wanting to try a completely 
>>>> different distro (I'm currently running off of Raspbian Lite).
>>>> Jonathan
>>>>
>>>> Sent from Yahoo Mail on Android
>>>>
>>>>  On Sat, Feb 22, 2020 at 1:28 AM, Nala Ginrut<address@hidden> wrote:
>>>> Thanks for spending your time Jaft!
>>>> The log showed weird things, it seems always get 0 as the socket fd.
>>>> To my understand, 0 is OK to be a valid socket fd, but it means the
>>>> program has closed stdin somewhere. I don't remember I did such
>>>> operation.
>>>>
>>>> The event-loop always get 0 from epoll_wait (three times in your
>>>> attached log), and close it each time. So it does nothing serving work.
>>>>
>>>> In the very beginning with the simplest test, the expected log to show
>>>> "Checking event" should be "Checking event (16 . 1)", and 16 is the
>>>> listenning socket in your log.
>>>> There's no way to check other event before getting any valid socket fd from
>>>> accepting the listenning socket. So the first checking should be the
>>>> listenning socket 16 according to your log.
>>>>
>>>> Do you have other distro on ARM to test? I suspect it's a wrong result
>>>> return from epoll_wait.
>>>>
>>>> Best regards.
>>>>
>>>>
>>>> Jaft writes:
>>>>
>>>>>  *it's the last thing put out before languishing. After things time out, 
>>>>> the rest of what's in the logs appear. Just wanted to mark when in the 
>>>>> logs things hang in case that info. is useful, any.
>>>>> Jonathan
>>>>>    On Friday, February 21, 2020, 7:45:56 PM CST, Jaft <address@hidden> 
>>>>> wrote:
>>>>>
>>>>>  No worries! I thought I was, as well, so perhaps I need to double check 
>>>>> that…
>>>>> I honestly wouldn't know. I didn't mess with any settings or the like 
>>>>> other than the port number.
>>>>> Though things do work on my local machine and not the pi so, perhaps, 
>>>>> there's a Raspberry Pi setting screwing things up I'm not aware of?
>>>>> In any case, I've attached the result of "art work --debug"; after 
>>>>> hitting Artanis, the last thing put out by art is "The client (0 . 1) is 
>>>>> ready to shutdown" and then things languish before eventually timing out.
>>>>> Jonathan    On Friday, February 21, 2020, 2:23:31 AM CST, Nala Ginrut 
>>>>> <address@hidden> wrote:
>>>>>
>>>>>
>>>>> Jaft writes:
>>>>>
>>>>>> artanis/server/epoll.scm:211:12: In procedure epoll-ctl:Throw to key
>>>>>> `artanis-err' with args `(500 #<procedure epoll-ctl (epfd op fd event
>>>>>> #:key check-exists?)> "~a: ~a" (15 2 0 #f "Bad file descriptor")
>>>>>> (9))'.
>>>>>
>>>>> Wait, why file descriptor 0 appeared here?
>>>>> 0 is stdin, obviously it can not be any connecting socket. It shouldn't
>>>>> even be added into epoll event set in Artanis.
>>>>>
>>>>> Now I'm suspecting it's not an Artanis bug.
>>>>> But anyway, please do as my last mail described, and attach the debug
>>>>> log please. Thanks!
>>>>>
>>>>> Best regards.
>>>>>
>>>>>
>>>>>
>>>>>> Jonathan
>>>>>>    On Thursday, February 20, 2020, 2:59:53 AM CST, Nala Ginrut 
>>>>>> <address@hidden> wrote:
>>>>>>
>>>>>>
>>>>>> Have you seen my other mails, I've obsoleted the patch that I gave you,
>>>>>> and resubmit a new one in the same branch name. So you have to delete
>>>>>> the old one and checkout the new one from the remote.
>>>>>>
>>>>>> https://gitlab.com/NalaGinrut/artanis/-/commit/08b87717ade40ad0d8fbe0a6c62620cdc30e6f56
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jaft writes:
>>>>>>
>>>>>>>  From the fix/epoll-exists-check branch?
>>>>>>> That's the one I pulled and built; the errors look similar but, if you 
>>>>>>> look at the very end of the error messages, the first one says 
>>>>>>> "artanis/server/epoll.scm:220:4: In procedure exists-in-epoll?:" while 
>>>>>>> my most recent error say "artanis/server/epoll.scm:211:12: In procedure 
>>>>>>> epoll-ctl:".
>>>>>>> Jonathan
>>>>>>>    On Thursday, February 20, 2020, 1:42:49 AM CST, Nala Ginrut 
>>>>>>> <address@hidden> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Could you try the refix version?
>>>>>>>
>>>>>>> Best regards.
>>>>>>>
>>>>>>> Jaft writes:
>>>>>>>
>>>>>>>>  Hey, Nala.
>>>>>>>> Unfortunately, no luck; I pulled the branch you mentioned and, after 
>>>>>>>> building it, I see the changes you made installed but get the below 
>>>>>>>> error:
>>>>>>>> ;;; note: source file /usr/bin/art;;;      newer than compiled 
>>>>>>>> /home/pi/.cache/guile/ccache/2.2-LE-4-3.A/usr/bin/art.go;;; note: 
>>>>>>>> auto-compilation is enabled, set GUILE_AUTO_COMPILE=0;;;      or pass 
>>>>>>>> the --no-auto-compile argument to disable.;;; compiling 
>>>>>>>> /usr/bin/art;;; compiled 
>>>>>>>> /home/pi/.cache/guile/ccache/2.2-LE-4-3.A/usr/bin/art.goLoading 
>>>>>>>> conf/artanis.conf...done.Session with SIMPLE backend init done!Loading 
>>>>>>>> models...Loading controllers...Loading restful API...Regenerating 
>>>>>>>> route cache ...Server core: ragnarokhttp://127.0.0.1:1234Anytime you 
>>>>>>>> want to quit just try Ctrl+C, thanks!Backtrace:          11 
>>>>>>>> (apply-smob/1 #<catch-closure 4dcdf0>)In ice-9/boot-9.scm:    705:2 10 
>>>>>>>> (call-with-prompt _ _ #<procedure default-prompt-handle…>)In 
>>>>>>>> ice-9/eval.scm:    619:8  9 (_ #(#(#<directory (guile-user) 
>>>>>>>> 4f6910>)))In /usr/bin/art:    42:12  8 (_ _ _)In 
>>>>>>>> artanis/commands/work.scm:    144:8  7 (work . _)In 
>>>>>>>> artanis/server/ragnarok.scm:  630:10  6 (establish-http-gateway _)  
>>>>>>>> 450:27  5 (ragnarok-http-gateway-run _)    420:6  4 
>>>>>>>> (get-one-request-from-clients #<r6rs:record:ragnarok-p…> …)    218:4  
>>>>>>>> 3 (fill-ready-queue-from-service _ #<r6rs:record:ragnarok…>)In 
>>>>>>>> ice-9/boot-9.scm:  260:13  2 (for-each #<procedure 65c2d0 at 
>>>>>>>> artanis/server/ragnaro…> …)In artanis/server/ragnarok.scm:  245:16  1 
>>>>>>>> (_ (0 . 1))In artanis/server/epoll.scm:  211:12  0 (epoll-ctl 15 _ 0 _ 
>>>>>>>> #:check-exists? _)
>>>>>>>> artanis/server/epoll.scm:211:12: In procedure epoll-ctl:Throw to key 
>>>>>>>> `artanis-err' with args `(500 #<procedure epoll-ctl (epfd op fd event 
>>>>>>>> #:key check-exists?)> "~a: ~a" (15 2 0 #f "Bad file descriptor") (9))'.
>>>>>>>> Jonathan
>>>>>>>>    On Wednesday, February 19, 2020, 4:12:15 AM CST, Nala Ginrut 
>>>>>>>> <address@hidden> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Jaft!
>>>>>>>> I found there's illogical bug in epoll module, please try 
>>>>>>>> fix/epoll-exists-check branch:
>>>>>>>> https://gitlab.com/NalaGinrut/artanis/-/commit/9d2338401cf422f7e22c4b5686d77e77a8a95fb4
>>>>>>>>
>>>>>>>> If it works then I'll merge ASAP.
>>>>>>>>
>>>>>>>> To someone who wants to learn about this bug, here's a brief
>>>>>>>> description.
>>>>>>>>
>>>>>>>> When a new connection event comes in, the server core (Ragnarok) will
>>>>>>>> check if it's already in epoll event set:
>>>>>>>> - yes: Then there should be a existing task and we restore it. But if 
>>>>>>>> no task, then we
>>>>>>>> just drop it. This is the part which raised the error by illogical 
>>>>>>>> checking.
>>>>>>>> - no: Create a new task for this connection.
>>>>>>>>
>>>>>>>> Thanks for the report!
>>>>>>>>
>>>>>>>> Best regards.
>>>>>>>>
>>>>>>>> Jaft writes:
>>>>>>>>
>>>>>>>>>  Hey, Nala!
>>>>>>>>> I've actually been running that each time, just to be safe.
>>>>>>>>> But it's not an old codebase I'm trying out; I downloaded the most 
>>>>>>>>> recent version of Artanis. ran "art create test", then ran "cd test", 
>>>>>>>>> and then ran "art work --refresh" and keep having this exact behavior.
>>>>>>>>> I didn't think this could be a cause of anything but, in case it's 
>>>>>>>>> helpful, I am running it off of a Raspberry Pi, this time.
>>>>>>>>> Jonathan    On Monday, February 17, 2020, 6:02:10 AM EST, Nala Ginrut 
>>>>>>>>> <address@hidden> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Jaft!
>>>>>>>>> If you upgrade Artanis then please run `art work --refresh` at least
>>>>>>>>> once to make sure all your webapp code been recompiled with the latest
>>>>>>>>> Artanis.
>>>>>>>>>
>>>>>>>>> You may take a look at the NOTE in the manual:
>>>>>>>>> https://www.gnu.org/software/artanis/manual/manual.html#orga8bda39
>>>>>>>>>
>>>>>>>>> Best regards.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jaft writes:
>>>>>>>>>
>>>>>>>>>>  Actually, it looks like the first call just hangs (sometimes, until 
>>>>>>>>>> it eventually times out) and a second call is what produces the 
>>>>>>>>>> error.
>>>>>>>>>> I know, in older versions, just generating a project and running it 
>>>>>>>>>> would produce a page that says an index file should be provided but 
>>>>>>>>>> that Artanis was up and running but I don't know if things have 
>>>>>>>>>> changed, on that front, since last I tried out Artanis and I now 
>>>>>>>>>> need to provide initial files for things to work out of the gate.
>>>>>>>>>> Jonathan
>>>>>>>>>>    On Saturday, February 15, 2020, 2:45:45 PM CST, Jaft 
>>>>>>>>>> <address@hidden> wrote:
>>>>>>>>>>
>>>>>>>>>>  I had recently downloaded the most recent release of Artanis and 
>>>>>>>>>> was just trying to get a generated project to run (no additional 
>>>>>>>>>> edits – other than changing the port –, like enabling database usage 
>>>>>>>>>> or the like).
>>>>>>>>>> However, trying to hit the running project results in this error:
>>>>>>>>>>
>>>>>>>>>> Loading conf/artanis.conf...done.Session with SIMPLE backend init 
>>>>>>>>>> done!Loading models...Loading controllers...Loading restful 
>>>>>>>>>> API...Regenerating route cache ...Server core: 
>>>>>>>>>> ragnarokhttp://127.0.0.1:1234Anytime you want to quit just try 
>>>>>>>>>> Ctrl+C, thanks!Backtrace:          11 (apply-smob/1 #<catch-closure 
>>>>>>>>>> ff83d0>)In ice-9/boot-9.scm:    705:2 10 (call-with-prompt _ _ 
>>>>>>>>>> #<procedure default-prompt-handle…>)In ice-9/eval.scm:    619:8  9 
>>>>>>>>>> (_ #(#(#<directory (guile-user) 1052910>)))In /usr/bin/art:    42:12 
>>>>>>>>>>  8 (_ _ _)In artanis/commands/work.scm:    144:8  7 (work . _)In 
>>>>>>>>>> artanis/server/ragnarok.scm:  630:10  6 (establish-http-gateway _)  
>>>>>>>>>> 450:27  5 (ragnarok-http-gateway-run _)    420:6  4 
>>>>>>>>>> (get-one-request-from-clients #<r6rs:record:ragnarok-p…> …)    218:4 
>>>>>>>>>>  3 (fill-ready-queue-from-service _ #<r6rs:record:ragnarok…>)In 
>>>>>>>>>> ice-9/boot-9.scm:  260:13  2 (for-each #<procedure 12f0060 at 
>>>>>>>>>> artanis/server/ragnar…> …)In artanis/server/ragnarok.scm:  245:16  1 
>>>>>>>>>> (_ (0 . 1))In artanis/server/epoll.scm:    220:4  0 
>>>>>>>>>> (exists-in-epoll? 15 0)
>>>>>>>>>> artanis/server/epoll.scm:220:4: In procedure exists-in-epoll?:Throw 
>>>>>>>>>> to key `artanis-err' with args `(500 #<procedure epoll-ctl (epfd op 
>>>>>>>>>> fd event #:key check-exists?)> "~a: ~a" (15 2 0 #f "Bad file 
>>>>>>>>>> descriptor") (9))'.
>>>>>>>>>>
>>>>>>>>>> I can't make out the cause so I thought I'd ask.
>>>>>>>>>> Thank you for any help!
>>>>>>>>>> Jonathan


--
GNU Powered it
GPL Protected it
GOD Blessed it
HFG - NalaGinrut
Fingerprint F53B 4C56 95B5 E4D5 6093 4324 8469 6772 846A 0058

Attachment: signature.asc
Description: PGP signature


reply via email to

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