Pike-devel June 2004

pike-devel@lists.lysator.liu.se

10 participants
18 discussions

OpenBSD and pike...
by Xavier Beaudouin 26 Jul '04

26 Jul '04

Hello, According to http://pike.ida.liu.se/generated/pikefarm/7.7/97_28/verifylog.txt We have : Doing tests in modules/files/testsuite (94 tests) 0: ++++++++++ ++++++++++ ++++++++++ ++++++++++ ++++++++++ 50: ++++++++++ ++++++++++ ++++++++++ +++--+++++ Available fds: 1024 Forking... ok. Doing simple tests. Testing dup & assign. / Testing accept. -\|/-\| Testing uni-directional shutdown on socket Testing uni-directional shutdown on pipe Testing 12 sockets. /-\| Testing 16 sockets. /-\| Testing 20 sockets. /-\|/- Testing 24 sockets. \|/-\| Testing 28 sockets. /-\|/-\| Testing 32 sockets. /-\|/-\| Testing 36 sockets. /-\|/-\|/- Testing 40 sockets. \|/-\|/-\| Testing 44 sockets. /-\|/-\|/-\| Testing 48 sockets. /-\Accept returned 0, errno: 9 64 open fds: 0 - 63 [WATCHDOG] Pike testsuite timeout, sending SIGABRT. Abort (core dumped) *** Error code 134 Gdb says (http://pike.ida.liu.se/generated/pikefarm/7.7/97_28/core.txt) : Core was generated by `pike'. Program terminated with signal 6, Abort trap. #0 0x12793dd in poll () Active threads Backtrace #0 0x12793dd in poll () #1 0x7ddfda0 in _thread_kern_poll () #2 0x7ddf746 in _thread_kern_sched () #3 0x7ddf971 in _thread_kern_sched_state () #4 0x7dd9d73 in poll () #5 0x1c112353 in handle_timeouts (ignored=0x0) at /usr/home/kiwi/xenoclient/pike-7.7/obsd.home.oav.net/buildtmp/Pike- v7.7-snapshot/src/modules/HTTPLoop/timeout.c:192 #6 0x7dd703d in _thread_start () #7 0x1f in ?? () Cannot access memory at address 0xffffffff. This bug is here for ages... for both pike 7.6 and 7.7 (I don't have pike 7.4 on xenofarm even my box is sending data... so I cannot compare... do xenofarm does some "blacklisting ????").. Can I help to fix that ? /Xavier -- Xavier Beaudouin - Unix System Administrator & Projects Leader. President of Kazar Organization : http://www.kazar.net/ Please visit http://caudium.net/, home of Caudium & Camas projects

5 7

Drowning in the Shuffler (SEGV)
by Stephen R. van den Berg 02 Jul '04

02 Jul '04

Picture this: ChiliMoon 2004, http.pike uses the Shuffler object. It works fine (after a few modifications to the do_log callback), except when I call up a CGI program. cgi.pike uses a wrapper that uses a pair of pipes to pass the data along. Now, doing an add_source for shuffler with the proper end of the pipe, will result in the pipe being read correctly (once, total amount read, no followup read that should have detected the end). After that, the content of that read() is lost. Trying something different, I add three add_source() calls before, and three add_source() calls after the add_source() for the pipe. The three preceding and trailing add_source() calls have a fixed string content. What happens now is: Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9081d48 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9f64770 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c45038 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9f5d690 <<-- pipe Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c45068 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c45098 <<-- const string Shuffle[0x9c98b00]:add_source(XX,0,-1) --> 0x9c988c8 <<-- const string Shuffle[0x9c98b00]:set_done_callback(0x8d0141c) Shuffle[0x9c98b00]:start() Shuffle[0x9c98b00]:_set_callbacks() Shuffle[0x9c98b00]:__set_calllbacks(Pike) ...CGIWrapper is being done... Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): sending(48) Shuffle[0x9c98b00]:__send_more_callback(): sending(48): sent 48 Shuffle[0x9c98b00]:_give_back(8144) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9081d48 Shuffle[0x9c98b00]:__send_more_callback(): sending(46) Shuffle[0x9c98b00]:__send_more_callback(): sending(46): sent 46 Shuffle[0x9c98b00]:_give_back(8146) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Without the patch attached below, the argument to __send_more_callback becomes -2 (from the leftovers.len), and the program crashes with a SEGV shortly after removing the callbacks. With the patch, the following happens: Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c45038 Shuffle[0x9c98b00]:__send_more_callback(): read pending Shuffle[0x9c98b00]:__remove_calllbacks(Pike) Shuffle[0x9c98b00]:_give_back(8192) Shuffle[0x9c98b00]:_set_callbacks() Shuffle[0x9c98b00]:__set_calllbacks(Pike) However, at this point: - Data has been read from the CGIWrapper - But no trace of that appears in the output - I.e. in the output the six constant strings simply stick together. Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9f5d690 Shuffle[0x9c98b00]:__send_more_callback(): sending(17) Shuffle[0x9c98b00]:__send_more_callback(): sending(17): sent 17 Shuffle[0x9c98b00]:_give_back(8175) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c45068 Shuffle[0x9c98b00]:__send_more_callback(): sending(16) Shuffle[0x9c98b00]:__send_more_callback(): sending(16): sent 16 Shuffle[0x9c98b00]:_give_back(8176) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c45098 Shuffle[0x9c98b00]:__send_more_callback(): sending(15) Shuffle[0x9c98b00]:__send_more_callback(): sending(15): sent 15 Shuffle[0x9c98b00]:_give_back(8177) Shuffle[0x9c98b00]:write_callback() Shuffle[0x9c98b00]:_send_more(0) Shuffle[0x9c98b00]:_request(8192) from (nil) Shuffle[0x9c98b00]:__send_more_callback(8192) Shuffle[0x9c98b00]:__send_more_callback(): source done: 0x9c988c8 Shuffle[0x9c98b00]:__send_more_callback(): no sources Shuffle[0x9c98b00]:_give_back(8192) Shuffle[0x9c98b00]:_all_done(0) Shuffle[0x9c98b00]:_all_done(0): Calling done callback: 0x8d0141c Shuffle[0x9c98b00]:sent_data() --> 189 Shuffle[0x9c98b00]:_remove_callbacks() Shuffle[0x9c98b00]:__remove_calllbacks(Pike) Shuffle[0x9c98b00]:exit() Now, besides this patch, which prevents it from segfaulting, I'm a bit lost now. The shuffler innards are a maze of twists, turns and callbacks. I must be close, but the non-linear program flow is difficult to decipher. -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "Very funny, Mr. Scott. Now beam down my clothes!"

8 41

Regexp.PCRE problem
by Alexander Demenshin 27 Jun '04

27 Jun '04

Hi, There is one problem with Regexp.PCRE when study() is called (or Regexp.PCRE.Studied()). exec() code (in cmod) contains the following: ---snip--- #ifdef PCRE_EXTRA_STUDY_DATA if (THIS->extra) opts|=PCRE_EXTRA_STUDY_DATA; #else /* FIXME: Throw an error if THIS->extra is set? */ #endif /* PCRE_EXTRA_STUDY_DATA */ ---snip--- and opts will be used later in call to pcre_exec(), but.. this is a bit incorrect, since this option should be set not in the call to pcre_exec(), but in pcre_extra struct (field "flags"). Hence, any call to exec()/split() etc. for studied PCRE gives an error (with PCRE 4.4): > Regexp re = Regexp.PCRE("([a-z]+)"); > re->split("123abc123"); error returned from exec: ERROR.BADOPTION In case of PCRE 3.9, it passes by, but it is only because there is no symbol PCRE_EXTRA_STUDY_DATA defined. Additionally, PCRE doc says (man pcreapi): ---snip--- Other flag bits should be set to zero. The study_data field is set in the pcre_extra block that is returned by pcre_study(), together with the appropriate flag bit. You should not set this yourself, but you can add to the block by setting the other fields. ---snip--- So, there is absolutely no need to pass any options to pcre_exec() call while handling exec(). I would commit a fix, but I am not sure how to regenerate file pcre_glue.cmod.compiled - or is it enough to make change in cmod and .compiled will be (re)generated automatically? Also, side note - the ovector size is defined as 3000 - isn't this an overkill for most cases? It will consume 12K of stack space with every call to exec() (at least, this space is not dynamically allocated, which would be even worse). Regards, /Al

3 3

Regexp.PCRE problem
by Mirar ＠ Pike developers forum 27 Jun '04

27 Jun '04

I'll patch away those lines now.

1 0

Language Shootout
by Peter Bortas (Kein Paket!) ＠ Pike (-) developers forum 23 Jun '04

23 Jun '04

It seems someone has taken it upon himself to maintain the Great Computer Language Shootout for a bit again: http://shootout.alioth.debian.org/

4 7

String.Buffer foo
by Mirar ＠ Pike developers forum 23 Jun '04

23 Jun '04

| % pike | Pike v7.7 release 3 running Hilfe v3.5 (Incremental Pike Frontend) | > string test="hej"; | > String.Buffer buf=String.Buffer(); | > (string)(buf+test[3..]); | (1) Result: "" | > buf+="hej"; | (2) Result: Buffer(3 /* 512 */) | > (string)(buf+test[3..]); | zsh: segmentation fault pike

1 0

pike, sTeam and caudium at the linuxtag 2004
by Martin Bähr 21 Jun '04

21 Jun '04

hi, we have again been given the opportunity to present pike at the linuxtag in germany. from the 23rd to the 26th of june we will be able to present pike together with caudium and sTeam. please make suggestions on what to present, to make pike interresting to the public. who is willing to come to karlsruhe? if you bring a sleepingbag there is free accomodation. if you are interrested please contact me. (even if you are not sure you can make it, you don't need to commit right away) http://www.linuxtag.org/2004/ http://www.linuxtag.org/2004/community/pavillon.html http://www.infodrom.org/Debian/events/LinuxTag2004/projects.php3 http://www.infodrom.org/Debian/events/LinuxTag2004/faq.html greetings, martin. -- looking for a job doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer travelling and working in europe open-steam.org unix system- bahai.or.at iaeste.(tuwien.ac|or).at administrator (stuts|black.linux-m68k).org is.schon.org Martin Bähr http://www.iaeste.or.at/~mbaehr/ _______________________________________________ Caudium-general mailing list caudium-general(a)caudium.net http://lists.oav.net/wws/info/caudium-general Archives are : http://lists.oav.net/wws/arc/caudium-general Caudium Website : http://caudium.net/

3 3

Re: scopes and destructors
by Stephen R. van den Berg 18 Jun '04

18 Jun '04

Martin Stjernholm wrote: >"Stephen R. van den Berg" <srb(a)cuci.nl> wrote: >> Ideal methods are threadsafe, and should be able to handle >> themselves in all cases. >Hardly relevant since pike isn't a toy for language purists. We don't >want to add thread safety in every function since it adds complexity >and overhead (and besides I don't see any way for the language to >enforce it without seriously crippling thread support). The same goes >for wrappers to avoid cycles. I think we're talking past each other here. I'm not saying that the language should enforce thread safety or anything else. I'm just saying that someone writing a class, should try to make the class threadsafe. >It's not hard to deal with these implicit properties if one only is >aware of them. It's much more efficient and imho also easier to treat >them as properties objects might or might not have, just like the >existence and type of any identifier. >Pike isn't alone in this. At least C++ and Java allow similar implicit >properties in object behavior, and I'd wager most other real world OO >languages do too. Yes, like I said above, that's a Good Thing. But that doesn't mean that someone writing a class should avoid these special properties if at all possible without excessive cost. >> Calling the destructors can be done, without freeing the actual memory; >> /.../ >No. Consider the case when there's an array, mapping or something else >that indirectly might contain objects. You have to free it to be sure >that the appropriate objects are destructed. I disagree (but, most likely, I still have the privilege to do this, because I'm not aware of the exact implementation Pike picked). Even if there's an array, mapping or something else that indirectly might contain objects; then it is not necessary to free this structure, it is only required to *traverse* this structure scouting for objects which have actual destructors defined. The actualy memory footprint can be left alone. But, for all I know, traversing the structure might be more difficult than simply freeing it. >> Besides, given the fact that programmers usually only use scopes within >> a function to limit the scope of a variable because they want to save >> memory, /.../ >Actually, that's not how I commonly use it. Most of the time I use it >to limit the visibility of the identifier to the narrowest possible >scope. In these cases I don't much care about when the memory really >is released. Ok, another possibility. I do this myself as well, but it's a practice I don't see a lot by anyone else. >Anyway, the memory has to be freed sooner or later anyhow, so the only >speed lost would be due to slightly larger code and some more >twiddling of the stack pointer, and I think that's negligible. I'd say the same (without knowing as much about the Pike implementation). >>>Note that inner functions make it a bit complicated to implement >>>popping at the end of scopes. Consider this case: >> That I realise. But that's a problem with actually freeing the memory, >> not with calling the destructors. >Sorry, but the same goes for destruction itself. It's trivial to adapt >my example so that there's an object that shouldn't be destructed when >the block is exited. Undoubtably true, but this discussion is not that important, since it will follow whatever constraints are given for correct operation. I just want to destruct objects which lose scope. If the object should be longer lived because of some reason, then so be it, then don't call the destructor yet. >> Ok, since we agree on the target. Any ideas on where to look in the >> Pike source? >Assuming that my suggestion from the other mail works, it's docode.c, >interpret_functions.h, language.yacc and probably a bunch of others. >Welcome to the world of the compiler and interpreter internals. ;) I'm not afraid. I did GCC development for more than a year, quite intensively in 1993-1995 (developing x86 register passing (coded in 14 days) and ending up fixing more collateral damage than I ever bargained for, all needed to support the 14 day hack for register passing). >(Moving the discussion to the pike devel list since it's clearly about >pike development now.) Ok, I just subscribed. On a related note, can I have write access to the Pike CVS repository? I agree to the rules. I promise to be a good boy. My username on the lysator.liu.se system for CVS is _cvs_stephen I'm already using it in the ChiliMoon project. I presume it can be reused for Pike. I'd need the CVS coordinates of the repository. I also wonder why the codelibrarian on lysator doesn't show Pike? To mast: Yes, I know that many of my suggested patches to Roxen have the appearance of being a bit shortsighted. That's not usually my practice of doing things. This behaviour is driven by the fact that (over the years) I've noticed that Roxen is slow in responding to bug reports/patch suggestions. So in order to make the chance of acceptance high, I minimise the change, so it's more easily understood. The other reason is that changes which have minimal impact on existing code, allow me to maintain long-term diff-versions of Roxen, without the need to check for conflicts every time the master source changes. Changing more to get better code (designwise), makes for larger exposure to change-conflicts. This is bad if you know that some changes will not get in for at least three years. In ChiliMoon you'll eventually be able to see what the remaining patches should have looked like (the ugly DB-patches you're still sitting on, are next on the list now (since Pike has been adapted now :-)). -- Sincerely, srb(a)cuci.nl Stephen R. van den Berg (AKA BuGless). "It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files." -- SysV.2 manual

2 1

fmod
by Mirar ＠ Pike developers forum 16 Jun '04

16 Jun '04

footnote: http://www.fmod.org

1 0

fmod
by Mirar ＠ Pike developers forum 16 Jun '04

16 Jun '04

Anyone imlemented a glue for fmod to Pike (or are working on it)?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel June 2004