Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3048 discussions

Pike-v7.4.20 @ OpenBSD-current
by Ian D (spellisteligist) ＠ Pike (-) developers forum 20 Jun '03

20 Jun '03

A binary package for Pike-stable on OpenBSD-current (ELF) is available at http://www.stacken.kth.se/~ian/Pike-v7.4.20-OpenBSD-3.3-i386 Hmm, maybe it isn't all that interesting for non-ELF people, but it's there :-)

2 2

Pike-v7.4.20 @ OpenBSD-current
by Ian D (spellisteligist) ＠ Pike (-) developers forum 20 Jun '03

20 Jun '03

Pike-v7.5.7-OpenBSD-3.3-i386 is also available there. Still ELF.

1 0

Calendar tweaks
by Johan Sundstr�m (folksk�dare) ＠ Pike (-) developers forum 19 Jun '03

19 Jun '03

Since I recall a bit of a stir last time we non-Mirars poked around in the Calendar module too silently, I thought I'd point out my addition of a format_commonlog() method, and a tzname_location() which digs out zone names like "Europe/Stockholm", when set. Perhaps the latter ought to return 0 rather than "CEST" or "UTC+1" for less defined zones? Another thought that just came up is that the support method tzname_utc_offset() I also took the liberty of providing (rendering the commonly used abhorration "+HHMM") might be better off static. Opinions welcome. :-)

1 0

POLLERR
by David Gourdelier 19 Jun '03

19 Jun '03

Hello, After compiling a Pike 7.4.21 with debug and a Caudium 1.3 on GNU/Linux (Debian unstable) with a 2.4.20 kernel, I have these messsages: Got POLLERR on fd 4 Got POLLERR on fd 4 Got POLLERR on fd 4 Got POLLERR on fd 2 Is it normal ? -- David Gourdelier

2 1

AutoDoc joins modules oddly
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 18 Jun '03

18 Jun '03

If I generate refdoc in a virgin 7.5 source tree, I get modules that are joined oddly. E.g. the top level Pike module has been joined with Parser.Pike: It says that it's a pike parser and shows an inherit from C.pmod together with the WEAK_* constants and the BacktraceFrame class etc. The doc on the pike site doesn't show this.

2 2

New windows build
by Peter Bortas ＠ Pike developers forum 17 Jun '03

17 Jun '03

There is a new windows build in the beta directory. It doesn't have a proper installer and it doesn't come with the support DLLs. I'll try to do another one in a couple of days when I get my new computer set up.

1 0

Pike localtime(), threads safe and low level localtime() / localtime_r() ?
by Xavier Beaudouin 17 Jun '03

17 Jun '03

Hi there, According to FreeBSD / Darwin / Linux man page, the low level function localtime() is not thread safe and we should use locatime_r() instead to avoid that. But the pike function localtime() use the low level localtime() ---/ from builtin_functions.c generated file - pike 7.4 /--- [...] PMOD_EXPORT void f_localtime(INT32 args) { struct tm *tm; INT_TYPE tt; time_t t; get_all_args("localtime", args, "%i", &tt); t = tt; tm = localtime(&t); if (!tm) Pike_error ("localtime() on this system cannot handle " "the timestamp %ld.\n", (long) t); pop_n_elems(args); encode_struct_tm(tm); [...] ---//-- Do you think it should be mutch better to - either use localtime_r() if OS support it and provide it - add a mutex or something to avoid threading problems. Thanks, /Xavier

6 21

Question about speed
by Peta, jo det �r jag ＠ Pike developers forum 12 Jun '03

12 Jun '03

As some of you probably know am I currently adding some ADTs to Pike, among those a sequence. I've been running some speed comparisons between the new sequence and the array regarding indexing and index assignment ( [] and []= ) and found that the array is about twice as fast as the sequence. I found this quite surprising since it use about the same code as the array, it is just a few rows extra, see the code below. Could the speed difference depends on the extra time it takes to find the '[]() lfun for the sequence? The CMOD-Code PIKEFUN mixed `[](mixed index) { simple_array_index_no_free(Pike_sp, THIS->a, index); Pike_sp++; } PIKEFUN mixed `[]=(mixed index, mixed value) { should_copy(); simple_set_index(THIS->a, index, value); } The final C-Code void f_Sequence_cq__backtick_5B_5D(INT32 args) { #line 67 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" struct svalue * index; #line 67 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" if(args != 1) wrong_number_of_args_error("`[]",args,1); #line 67 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" index=Pike_sp+0-1; dmalloc_touch_svalue(Pike_sp+0-1); #line 67 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" { simple_array_index_no_free(Pike_sp, THIS->a, index); Pike_sp++; } void f_Sequence_cq__backtick_5B_5D_eq(INT32 args) { #line 89 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" struct svalue * index; #line 89 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" struct svalue * value; #line 89 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" if(args != 2) wrong_number_of_args_error("`[]=",args,2); #line 89 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" index=Pike_sp+0-2; dmalloc_touch_svalue(Pike_sp+0-2); #line 89 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" value=Pike_sp+1-2; dmalloc_touch_svalue(Pike_sp+1-2); #line 89 "/export/spare/pike/home/peta/Pike/7.5/src/post_modules/_ADT/sequence.c mod" { should_copy(); simple_set_index(THIS->a, index, value); }

3 2

Debugging memory problems
by David Gourdelier 11 Jun '03

11 Jun '03

Hello, We have a memory leak inside Camas (and it exists most propably on IMHO as well). I've tried to debug in order to find where the leak is (I used Pike 7.2). We know the leak is inside the session object, it contains all sort of variables including other objects, mapping, string and so on (people interested in the source can get it here <http://cvsweb.caudiumforge.net/cgi-bin/cvsweb.cgi/camas/server/modules/cama…>). I've tried to force gc() every x minutes and when the user logout but it doesn't change the problem. I also added this in the destroy function of the session: void destroy_object(object o) { if(o && objectp(o)) destruct(o); } void destroy() { foreach(indices(this_object()), string var) { if(this_object()[var] && !intp(this_object()[var])) { int refs = _refs(this_object()[var]); if(refs > 2) write("variable %s is referenced %d times\n", var, refs); } } destroy_object(lock); destroy_object(imapclient); destroy_object(cmail); destroy_object(prefsmailobj); destroy_object(extendedabook); destroy_object(ebookmailobj); destruct(this_object()); } Which shows me lot of variables are referenced several times and for some of then, more than 7000 times. I also noted that the variables are usually referenced by similar number of other variables, for example I have this output: variable draftmail is referenced 1107 times variable misspelled is referenced 7067 times variable spelling is referenced 7067 times variable deletemails is referenced 7067 times variable deletemboxes is referenced 7067 times variable prefuids is referenced 7067 times variable searchstring is referenced 1107 times variable session is referenced 1107 times I also saw the destroy or dump_me functions are referenced 8 times while they are not used by other things in the program. So my first questions are: . How can I have so much objects referenced ? Is it because of some sort of reference loop ? Is _refs() working good on Pike 7.2 ? . What does a reference for a function mean ? . Is it possible to know which things reference which variables ? . What is the effect of adding a destroy() inside an object ? I also enable debug in gc.c to find the problem but the output looks quite cryptic to me. At the beginning of the destroy I have this: Garbage collecting ... | check: 33151 references checked, counted 489 weak refs | mark: 15799 markers referenced, 0 weak references freed, | 0 things really freed, got 0 tricky weak refs Then lot of enqueue 0x89223ec [(nil)]: back=(nil), prev=0x81d1990, next=(nil), data=0x850cd2 4, cycle=0, flags=0x01 gc_cycle_push, recurse 0x850cd24 [(nil)] marker at 0x89495ec: flags =0x6446, refs=1, weak=-1, xrefs=0, saved=0, frame=0x89223ec [back=(nil), prev=0x 81d1990, next=(nil), data=0x850cd24, cycle=0, flags=0x01] ... dequeue 0x89222b4 [0x89222cc]: back=0x89222cc, prev=0x89223ec, next=(nil), data= 0x88ade1c, cycle=0, flags=0x01 gc_cycle_pop, pop off 0x88ade1c [0x8606e0c] marker at 0x898bb2c: flags=0x040e, refs=1, weak=0, xrefs=0, saved=1, frame=0x89222b4 [back=0xfffffff f, prev=0x89223ec, next=(nil), data=0x88ade1c, cycle=0, flags=0x09] .... gc_cycle_push, no recurse 0x88ad8ac [(nil)] marker at 0x89986b4: flags =0x040e, refs=1, weak=0, xrefs=0, saved=1, frame=(nil) and finally: | cycle: 554 internal things visited, 14 cycle ids used, | 0 weak references freed, 0 things really freed, | space for 48 gc frames used | free: 26 really freed, 528 left with live references | Killing 0x850e4c4 with 25 refs .... | Killing 0x8606e0c with 25 refs | kill: 23 objects killed, 528 things really freed | destruct: 0 things really freed done (freed 554 of 14900 objects) . Can someone explained a little the output if it worth it ? Especially I would like to know what is a weak reference ? Why some references are weaker than others ? what does object killed mean ? I also want to know if _next() and _prev() can be of any help to me and if yes how can I use it ? Thank you for your time. -- David Gourdelier

4 18

Post-padding overwritten
by David Gourdelier 09 Jun '03

09 Jun '03

Hi, I've compiled Pike with --with-dmalloc --with-dmalloc-malloc-leaks --with-checker --with-rtldebug and when I load Caudium I get the following error when it loads one of the Camas modules: Loading camas_tags... Post-padding overwritten for block at 0xac7bda0 (size 20)! **Location: 0xac7bda0 Type: unknown Refs: 0 gc generation: 11/11 gc pass: 0/0 *** peep.c:187 (1 times) *** pike_memory.c:570 (1 times) **Cannot describe block of unknown type 247 ******************* Then the pike process exit. The previous modules loads without warning. Can you tell me what this mean ? -- David Gourdelier

5 6

Jump to page:

2026

2025

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