Pike-devel

pike-devel@lists.lysator.liu.se

3044 discussions

Pike 7.2 not exported
by David Gourdelier 24 May '04

24 May '04

Hi, While trying the Pike 7.2 official releases at ftp://pike.ida.liu.se/pub/pike/all/7.2.239/ and ftp://pike.ida.liu.se/pub/pike/all/7.2.197/, I saw these versions are not exported: Compiling /home/david/archives/Pike-v7.2.197/src/queue.c ./precompile.sh precompile.pike >"/home/david/archives/Pike-v7.2.197/src/builtin.c" "/home/david/archives/Pike-v7.2.197/src/builtin.cmod" || { rm "/home/david/archives/Pike-v7.2.197/src/builtin.c"; exit 1; } precompile: /home/david/archives/Pike-v7.2.197/src/pike -DNOT_INSTALLED -m/home/david/archives/Pike-v7.2.197/src/master.pike ./precompile.pike /home/david/archives/Pike-v7.2.197/src/builtin.cmod (method=Q) ./precompile.sh: /home/david/archives/Pike-v7.2.197/src/pike: not found precompile: /home/david/archives/Pike-v7.2.197/src/tpike -DNOT_INSTALLED -m/home/david/archives/Pike-v7.2.197/src/master.pike ./precompile.pike /home/david/archives/Pike-v7.2.197/src/builtin.cmod (method=QQ) ./precompile.sh: /home/david/archives/Pike-v7.2.197/src/tpike: not found precompile: /home/david/archives/Pike-v7.2.197/src/test-pike ./precompile.pike /home/david/archives/Pike-v7.2.197/src/builtin.cmod (method=QQQ) ./precompile.sh: /home/david/archives/Pike-v7.2.197/src/test-pike: not found precompile: pike -DOLD ./precompile.pike /home/david/archives/Pike-v7.2.197/src/builtin.cmod (method=QQQQQQ) pike: not found blabla.... / David

1 0

Re: Suggestions to manual
by Martin Bähr 19 May '04

19 May '04

i am changing the list, as this is not relevant for pike users. On Tue, May 18, 2004 at 03:46:44PM +0200, Martin Stjernholm wrote: > > mixed m; > > typeof(m); > (1) Result: mixed > > typeof([int] m); > (2) Result: int > > Only the type is changed, hence a type cast. A normal cast like > (int) "1" changes the value, hence a value cast. the difference is than that [type] only changes the variable but not its value, whereas (type) changes both. in other languages (see the c and java examples), the term "type cast" is used to describe the first case where where both variable and value are changed. hence i think it is a bad idea to use a different definition in pike. coining new terms is fine, but chaning existing ones will lead to confusion. "variable cast" might work. greetings, martin.

5 5

Syslog fix
by David Gourdelier 19 May '04

19 May '04

Hi, I think there is a bug in system/syslog.c: if(i & (1<<0)) pri |= LOG_EMERG; if(i & (1<<1)) pri |= LOG_ALERT; if(i & (1<<2)) pri |= LOG_CRIT; if(i & (1<<3)) pri |= LOG_ERR; if(i & (1<<4)) pri |= LOG_WARNING; if(i & (1<<5)) pri |= LOG_NOTICE; if(i & (1<<6)) pri |= LOG_INFO; if(i & (1<<6)) pri |= LOG_DEBUG; Shouldn't it be 1<<7 instead of 1<<6 for the last line ? -- David Gourdelier

2 1

some observations on the build process
by Martin Bähr 19 May '04

19 May '04

hi, when building pike 7.6 from cvs i noticed a few things that could be improved: after configure a summary of what was detected is shown. but when you just run make as suggested then you never see that summary because it gets buried in the compile outbut following it. hence it would be nice to show that summary after a complete make run as well. after finding that a lot of libs were missing to build GL and all that i found that after installing them neither make force_autoconfig nor make force_configure not even make clean would do anything to update the findings. i had to remove the whole build tree to get the new libs detected. greetings, martin.

9 12

Pike @ win32
by Marcus Agehall (Scanian) ＠ Pike (-) developers forum 19 May '04

19 May '04

I've just committed an initial patch that allows Pike to be compiled using mingw32. To compile pike using mingw32, you will have to do the following: 1) Install the latest mingw32-dist 2) Install Msys 3) Install the mingw Win32 API update 4) Install GMP (either from source or bin package) 5) Install Nettle (untested! I've been using --without-nettle for the time beeing...) 6) Get a Pike 7.7 source snapshot (or build one yourself). Building from CVS under mingw32 seems to break due to some cr/lf problem, so build the source-dist on a unix box. 7) Set the PIKE_PATH_TRANSLATE to some sed-command which translates the master-paths from you MSYS installation to the regular NT-CMD filesystem(*). 8) Do "make configure" to configure your buildtree. 9) Do "make" do build pike. 10) (optional) Do "make verify". This will fail, the hard way.. ;( 11) You should now have a pike which is usable to some extent. I havn't tested it much, but I've done some simple tests and it seems to hold up fairly well. (*) I build from my home-dir, /home/SSS668. To create a working master, I need to translate that path to c:/msys/1.0/home/SSS668. You need to do the same using some creative sed-command or accept that your build will fail when it attepmts to build post_modules. You can modify the master manually if you like. Look for the ¤-sign to find what places to modify. So, there it is. Now you should know what you need to build. I believe that Mingw32 is the easiest way to get Pike to compile on Win32. However, I'm not so certain it is the best choice since there seems to be quite a few compatibility issues between mingw32 and the win32 api (as MS provides it). I have access to both at work and they do not match in several places. I believe that we should try to get Pike to work with mingw first, and then start working towards MSVC native compilation. However, there will still be the problem of configuring the build. It may be that we always will need a msys-layer to run configure.

5 9

Re: Nettle cmod segfault
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 19 May '04

19 May '04

> I think, like many others, that there are too complex macros in Pike and > that it's a big problem for code readibility. I guess you're talking of things like the block_alloc system, fsort.h, the volymous macros for doing string stuff once for each string width, and the undisputed king of the hill: The interpret_functions.h macro system. Things like THREADS_DISALLOW is just an ordinary macro and can hardly be considered a readability problem. I know what you mean; I got fairly frustrated too the first time I tried to grep through the source for the definition of get_marker and couldn't find it anywhere. Still, once you've groked how it works it's damn handy. Some of the string processing stuff could probably have been written without macros and instead accept the performance hit, and it got to be possible to clean up the interpret_functions.h stuff somehow. Using macros to at compile time choose between a heap of separate functions and a giant case is a bit over the edge imho; trusting function inlining just a little would have made it a lot simpler. But apart from that, you have to consider what the alternatives would be before dissing it (which doesn't imply that I think every single remaining macro is altogether nice and tidy, though). For e.g. block_alloc and fsort, I can only think of C++ templates as being able to improve it in any way. / Martin Stjernholm, Roxen IS Previous text: >2004-05-18 12:39: >Subject: Re: Nettle cmod segfault >-------------------------------------------------------------------- >Martin Stjernholm, Roxen IS @ Pike developers forum wrote: >>>As we are speaking of that, wouldn't it be possible to make this macros >>>with a little less code in it (and generally in macros used in Pike)? >> >> >> Possible - yes. A good idea - probably not. I've looked at many of the >> macros and usually think they make sense, at least when rtldebug and >> dmalloc isn't enabled. For the most part, they get overly bloated only >> when debug is enabled; it's not uncommon that the debug parts are a >> bit sloppy and don't bother to isolate some overly long debug checks >> into functions. > >I think, like many others, that there are too complex macros in Pike and >that it's a big problem for code readibility. > >Anyway about the debug, I compiled with rtldebug but Pike doesn't seem >to care much about it, at least I have the same output during the >segfault. I uncomment VERBOSE_THREADS_DEBUG in pike_threadlib.h thought. >Here is the result: > >(Isn't the problem is that THREADS_DISALLOW is called 2 times without >THREADS_ALLOW in between backend.cmod and hash.cmod ?) > >THREADS_ALLOW() /home/david/Pike/7.6/src/backend.cmod:2333 t:08383000(#0) >THREADS_DISALLOW() >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 t: >08ded800(#0) >KEY k:0xa043d80, o:0x8bf3000 >LOCK k:0xa043d80, m:0x8c07ad0(0x8c07ad0), t:0x8bf3000 >KEY k:0xa043dc0, o:0x8bf3000 >LOCK k:0xa043dc0, m:0x8c07a70(0x8c07a70), t:0x8bf3000 >UNLOCK k:0xa043dc0 m:(0x8c07a70) t:0x8bf3000 o:0x8bf3000 >THREADS_ALLOW() >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:136 t:08d >ed800(#0) >THREADS_DISALLOW() /home/david/Pike/7.6/src/backend.cmod:2340 t:08383000(#0) >THREADS_DISALLOW() >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 t: >08ded800(#0) >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138: Fatal error: > >Program received signal SIGSEGV, Segmentation fault. >0x2861755a in f_HashState_update (args=1) > at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 >138 THREADS_DISALLOW(); >#0 0x2861755a in f_HashState_update (args=1) > at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 >#1 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db1688, > arg2=0x3) at /home/david/Pike/7.6/src/apply_low.h:214 >#2 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=1) > at /home/david/Pike/7.6/src/interpret_functions.h:1958 >#3 0x856b339 in ?? () >#4 0x8070f3e in eval_instruction ( > pc=0x856b138 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#5 0x808ac41 in o_catch (pc=0x856b138 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:2027 >#6 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#7 0x856b132 in ?? () >#8 0x8070f3e in eval_instruction ( > pc=0x90d1328 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#9 0x808ac41 in o_catch (pc=0x90d1328 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:2027 >#10 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#11 0x90d1322 in ?? () >---Type <return> to continue, or q <return> to quit--- >#12 0x8070f3e in eval_instruction (pc=0x9571fd8 "ÇD$\004\005") > at /home/david/Pike/7.6/src/interpret.c:1229 >#13 0x808ac41 in o_catch (pc=0x9571fd8 "ÇD$\004\005") > at /home/david/Pike/7.6/src/interpret.c:2027 >#14 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#15 0x9571fd2 in ?? () >#16 0x8070f3e in eval_instruction ( > pc=0x956dbc6 "\213\r0\207.\b¸:$©ö÷Ø\211A\034ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#17 0x808ab04 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) > at /home/david/Pike/7.6/src/interpret.c:1982 >#18 0x808ad50 in f_call_function (args=8) > at /home/david/Pike/7.6/src/interpret.c:2053 >#19 0x285f890d in container_callback (this=0xa005d00, thisobj=0x8db2cd8, > v=0x98b4360, startc=0x8b0e588, cstartc=2006, endc=0x8b0e588, >cendc=3885, > st=0x852efb0, cutstart=0x852efbc, ccutstart=0x852efc0, >cutend=0x8b0e588, > ccutend=3892) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 >#20 0x285fabe0 in do_try_feed (this=0xa005d00, thisobj=0x8db2cd8, > st=0x852efb0, feed=0x852efbc, finished=1, ignore_tag_cb=0) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 >#21 0x285fc942 in try_feed (finished=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 >---Type <return> to continue, or q <return> to quit--- >#22 0x285fd3de in html_finish (args=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 >#23 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db2cd8, > arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 >#24 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=55) > at /home/david/Pike/7.6/src/interpret_functions.h:1958 >#25 0x9571a8b in ?? () >#26 0x8070f3e in eval_instruction ( > pc=0x956dbc6 "\213\r0\207.\b¸:$©ö÷Ø\211A\034ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#27 0x808ab04 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) > at /home/david/Pike/7.6/src/interpret.c:1982 >#28 0x808ad50 in f_call_function (args=8) > at /home/david/Pike/7.6/src/interpret.c:2053 >#29 0x285f890d in container_callback (this=0xa005f00, thisobj=0x8db2ed0, > v=0x98b4570, startc=0x8b0e5a0, cstartc=123, endc=0x8b0e5a0, >cendc=16534, > st=0x852ef70, cutstart=0x852ef7c, ccutstart=0x852ef80, >cutend=0x8b0e5a0, > ccutend=16541) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 >#30 0x285fabe0 in do_try_feed (this=0xa005f00, thisobj=0x8db2ed0, > st=0x852ef70, feed=0x852ef7c, finished=1, ignore_tag_cb=0) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 >#31 0x285fc942 in try_feed (finished=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 >---Type <return> to continue, or q <return> to quit--- >#32 0x285fd3de in html_finish (args=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 >#33 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db2ed0, > arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 >#34 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=55) > at /home/david/Pike/7.6/src/interpret_functions.h:1958 >#35 0x9571a8b in ?? () >#36 0x8070f3e in eval_instruction (pc=0x8c99b06 "ÇD$\004\e") > at /home/david/Pike/7.6/src/interpret.c:1229 >#37 0x808ac41 in o_catch (pc=0x8c99b06 "ÇD$\004\e") > at /home/david/Pike/7.6/src/interpret.c:2027 >#38 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#39 0x8c99b00 in ?? () >#40 0x8070f3e in eval_instruction ( > pc=0x8b2f564 "¡0\207.\b\203@\034\017ÇD$\004\234") > at /home/david/Pike/7.6/src/interpret.c:1229 >#41 0x808ac41 in o_catch (pc=0x8b2f564 "¡0\207.\b\203@\034\017ÇD$\004\234") > at /home/david/Pike/7.6/src/interpret.c:2027 >#42 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#43 0x8b2f55e in ?? () >#44 0x8070f3e in eval_instruction ( >---Type <return> to continue, or q <return> to quit--- > pc=0x8b2f527 "\213\r0\207.\b¸Ù\nM÷÷Ø\211A\034Ç\004$\226") > at /home/david/Pike/7.6/src/interpret.c:1229 >#45 0x808ab04 in mega_apply (type=APPLY_STACK, args=2, arg1=0x0, arg2=0x0) > at /home/david/Pike/7.6/src/interpret.c:1982 >#46 0x808ad50 in f_call_function (args=2) > at /home/david/Pike/7.6/src/interpret.c:2053 >#47 0x8165cde in new_thread_func (data=0xbfbfef6c) > at /home/david/Pike/7.6/src/threads.c:868 >#48 0x282e71b4 in _thread_start () from /usr/lib/libc_r.so.4 >#49 0x0 in ?? () > > > > / Brevbäraren >

2 1

Nettle cmod segfault
by David Gourdelier 18 May '04

18 May '04

Hi list, I have a segfault when using the Nettle cmod under FreeBSD 4.7, it seems to be related to threads: /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138: Fatal error: Program received signal SIGSEGV, Segmentation fault. 0x2860f340 in f_HashState_update (args=1) at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 138 THREADS_DISALLOW(); (gdb) display data->len 2: data->len = 56 (gdb) display (char*)data->str 4: ( char *) data->str = 0xa06d014 "camas_fix_coding://Bertrand LUPART <bertrand(a)linkeo.com>" (gdb) bt #0 0x2860f340 in f_HashState_update (args=1) at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 #1 0x8088500 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8da9e20, arg2=0x3) at /home/david/Pike/7.6/src/apply_low.h:214 #2 0x8083614 in jump_opcode_F_CALL_OTHER (arg1=1) at /home/david/Pike/7.6/src/interpret_functions.h:1958 #3 0x8563339 in ?? () #4 0x8070eea in eval_instruction ( pc=0x8563138 "¡0\025.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #5 0x808abed in o_catch (pc=0x8563138 "¡0\025.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:2027 #6 0x807c1a4 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #7 0x8563132 in ?? () #8 0x8070eea in eval_instruction ( pc=0x90c9328 "¡0\025.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #9 0x808abed in o_catch (pc=0x90c9328 "¡0\025.\b\203@\034\024ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:2027 #10 0x807c1a4 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #11 0x90c9322 in ?? () ---Type <return> to continue, or q <return> to quit--- #12 0x8070eea in eval_instruction (pc=0x9571fd8 "ÇD$\004\005") at /home/david/Pike/7.6/src/interpret.c:1229 #13 0x808abed in o_catch (pc=0x9571fd8 "ÇD$\004\005") at /home/david/Pike/7.6/src/interpret.c:2027 #14 0x807c1a4 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #15 0x9571fd2 in ?? () #16 0x8070eea in eval_instruction ( pc=0x956dbc6 "\213\r0\025.\b¸:$©ö÷Ø\211A\034ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #17 0x808aab0 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) at /home/david/Pike/7.6/src/interpret.c:1982 #18 0x808acfc in f_call_function (args=8) at /home/david/Pike/7.6/src/interpret.c:2053 #19 0x285f087d in container_callback (this=0xa02a600, thisobj=0x8da9e08, v=0x98cc258, startc=0x8b96180, cstartc=2006, endc=0x8b96180, cendc=3885, st=0x8892f30, cutstart=0x8892f3c, ccutstart=0x8892f40, cutend=0x8b96180, ccutend=3892) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 #20 0x285f2b50 in do_try_feed (this=0xa02a600, thisobj=0x8da9e08, st=0x8892f30, feed=0x8892f3c, finished=1, ignore_tag_cb=0) at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 #21 0x285f48b2 in try_feed (finished=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 ---Type <return> to continue, or q <return> to quit--- #22 0x285f534e in html_finish (args=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 #23 0x8088500 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8da9e08, arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 #24 0x8083614 in jump_opcode_F_CALL_OTHER (arg1=55) at /home/david/Pike/7.6/src/interpret_functions.h:1958 #25 0x9571a8b in ?? () #26 0x8070eea in eval_instruction ( pc=0x956dbc6 "\213\r0\025.\b¸:$©ö÷Ø\211A\034ÇD$\004") at /home/david/Pike/7.6/src/interpret.c:1229 #27 0x808aab0 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) at /home/david/Pike/7.6/src/interpret.c:1982 #28 0x808acfc in f_call_function (args=8) at /home/david/Pike/7.6/src/interpret.c:2053 #29 0x285f087d in container_callback (this=0xa010400, thisobj=0x8da9c70, v=0x98cc720, startc=0x8b96190, cstartc=123, endc=0x8b96190, cendc=16534, st=0x8892f50, cutstart=0x8892f5c, ccutstart=0x8892f60, cutend=0x8b96190, ccutend=16541) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 #30 0x285f2b50 in do_try_feed (this=0xa010400, thisobj=0x8da9c70, st=0x8892f50, feed=0x8892f5c, finished=1, ignore_tag_cb=0) at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 #31 0x285f48b2 in try_feed (finished=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 ---Type <return> to continue, or q <return> to quit--- #32 0x285f534e in html_finish (args=1) at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 #33 0x8088500 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8da9c70, arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 #34 0x8083614 in jump_opcode_F_CALL_OTHER (arg1=55) at /home/david/Pike/7.6/src/interpret_functions.h:1958 #35 0x9571a8b in ?? () #36 0x8070eea in eval_instruction (pc=0x8c90b06 "ÇD$\004\e") at /home/david/Pike/7.6/src/interpret.c:1229 #37 0x808abed in o_catch (pc=0x8c90b06 "ÇD$\004\e") at /home/david/Pike/7.6/src/interpret.c:2027 #38 0x807c1a4 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #39 0x8c90b00 in ?? () #40 0x8070eea in eval_instruction ( pc=0x8b27564 "¡0\025.\b\203@\034\017ÇD$\004\234") at /home/david/Pike/7.6/src/interpret.c:1229 #41 0x808abed in o_catch (pc=0x8b27564 "¡0\025.\b\203@\034\017ÇD$\004\234") at /home/david/Pike/7.6/src/interpret.c:2027 #42 0x807c1a4 in jump_opcode_F_CATCH () at /home/david/Pike/7.6/src/interpret_functions.h:1240 #43 0x8b2755e in ?? () #44 0x8070eea in eval_instruction ( ---Type <return> to continue, or q <return> to quit--- pc=0x8b27527 "\213\r0\025.\b¸Ù\212M÷÷Ø\211A\034Ç\004$\226") at /home/david/Pike/7.6/src/interpret.c:1229 #45 0x808aab0 in mega_apply (type=APPLY_STACK, args=2, arg1=0x0, arg2=0x0) at /home/david/Pike/7.6/src/interpret.c:1982 #46 0x808acfc in f_call_function (args=2) at /home/david/Pike/7.6/src/interpret.c:2053 #47 0x8164fe2 in new_thread_func (data=0xbfbfef3c) at /home/david/Pike/7.6/src/threads.c:868 #48 0x282e01b4 in _thread_start () from /usr/lib/libc_r.so.4 #49 0x0 in ?? () The problem seems to happen everytime now just after I upgraded my Pike to the CVS version. I had a 7.6.6 before and it was working fine. / David

5 15

Re: Nettle cmod segfault
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 18 May '04

18 May '04

>Anyway about the debug, I compiled with rtldebug but Pike doesn't seem >to care much about it, at least I have the same output during the >segfault. I uncomment VERBOSE_THREADS_DEBUG in pike_threadlib.h thought. >Here is the result: > >(Isn't the problem is that THREADS_DISALLOW is called 2 times without >THREADS_ALLOW in between backend.cmod and hash.cmod ?) The nesting looks correct, but it seems low_mt_lock_interpreter() succeeds twice. The trace shows two threads, one in the backend, and one in Nettle: backend.cmod:2333 THREADS_ALLOW() hash.cmod:138 THREADS_DISALLOW() hash.cmod:136 THREADS_ALLOW() backend.cmod:2340 THREADS_DISALLOW() hash.cmod:138 THREADS_DISALLOW() The THREADS_DISALLOW() in hash.cmod:138 ought to have hung in low_mt_lock_interpreter(). / Henrik Grubbström (Lysator) Previous text: >2004-05-18 12:39: >Subject: Re: Nettle cmod segfault >-------------------------------------------------------------------- >Martin Stjernholm, Roxen IS @ Pike developers forum wrote: >>>As we are speaking of that, wouldn't it be possible to make this macros >>>with a little less code in it (and generally in macros used in Pike)? >> >> >> Possible - yes. A good idea - probably not. I've looked at many of the >> macros and usually think they make sense, at least when rtldebug and >> dmalloc isn't enabled. For the most part, they get overly bloated only >> when debug is enabled; it's not uncommon that the debug parts are a >> bit sloppy and don't bother to isolate some overly long debug checks >> into functions. > >I think, like many others, that there are too complex macros in Pike and >that it's a big problem for code readibility. > >Anyway about the debug, I compiled with rtldebug but Pike doesn't seem >to care much about it, at least I have the same output during the >segfault. I uncomment VERBOSE_THREADS_DEBUG in pike_threadlib.h thought. >Here is the result: > >(Isn't the problem is that THREADS_DISALLOW is called 2 times without >THREADS_ALLOW in between backend.cmod and hash.cmod ?) > >THREADS_ALLOW() /home/david/Pike/7.6/src/backend.cmod:2333 t:08383000(#0) >THREADS_DISALLOW() >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 t: >08ded800(#0) >KEY k:0xa043d80, o:0x8bf3000 >LOCK k:0xa043d80, m:0x8c07ad0(0x8c07ad0), t:0x8bf3000 >KEY k:0xa043dc0, o:0x8bf3000 >LOCK k:0xa043dc0, m:0x8c07a70(0x8c07a70), t:0x8bf3000 >UNLOCK k:0xa043dc0 m:(0x8c07a70) t:0x8bf3000 o:0x8bf3000 >THREADS_ALLOW() >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:136 t:08d >ed800(#0) >THREADS_DISALLOW() /home/david/Pike/7.6/src/backend.cmod:2340 t:08383000(#0) >THREADS_DISALLOW() >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 t: >08ded800(#0) >/home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138: Fatal error: > >Program received signal SIGSEGV, Segmentation fault. >0x2861755a in f_HashState_update (args=1) > at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 >138 THREADS_DISALLOW(); >#0 0x2861755a in f_HashState_update (args=1) > at /home/david/Pike/7.6/src/post_modules/Nettle/hash.cmod:138 >#1 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db1688, > arg2=0x3) at /home/david/Pike/7.6/src/apply_low.h:214 >#2 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=1) > at /home/david/Pike/7.6/src/interpret_functions.h:1958 >#3 0x856b339 in ?? () >#4 0x8070f3e in eval_instruction ( > pc=0x856b138 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#5 0x808ac41 in o_catch (pc=0x856b138 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:2027 >#6 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#7 0x856b132 in ?? () >#8 0x8070f3e in eval_instruction ( > pc=0x90d1328 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#9 0x808ac41 in o_catch (pc=0x90d1328 "¡0\207.\b\203@\034\024ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:2027 >#10 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#11 0x90d1322 in ?? () >---Type <return> to continue, or q <return> to quit--- >#12 0x8070f3e in eval_instruction (pc=0x9571fd8 "ÇD$\004\005") > at /home/david/Pike/7.6/src/interpret.c:1229 >#13 0x808ac41 in o_catch (pc=0x9571fd8 "ÇD$\004\005") > at /home/david/Pike/7.6/src/interpret.c:2027 >#14 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#15 0x9571fd2 in ?? () >#16 0x8070f3e in eval_instruction ( > pc=0x956dbc6 "\213\r0\207.\b¸:$©ö÷Ø\211A\034ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#17 0x808ab04 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) > at /home/david/Pike/7.6/src/interpret.c:1982 >#18 0x808ad50 in f_call_function (args=8) > at /home/david/Pike/7.6/src/interpret.c:2053 >#19 0x285f890d in container_callback (this=0xa005d00, thisobj=0x8db2cd8, > v=0x98b4360, startc=0x8b0e588, cstartc=2006, endc=0x8b0e588, >cendc=3885, > st=0x852efb0, cutstart=0x852efbc, ccutstart=0x852efc0, >cutend=0x8b0e588, > ccutend=3892) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 >#20 0x285fabe0 in do_try_feed (this=0xa005d00, thisobj=0x8db2cd8, > st=0x852efb0, feed=0x852efbc, finished=1, ignore_tag_cb=0) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 >#21 0x285fc942 in try_feed (finished=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 >---Type <return> to continue, or q <return> to quit--- >#22 0x285fd3de in html_finish (args=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 >#23 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db2cd8, > arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 >#24 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=55) > at /home/david/Pike/7.6/src/interpret_functions.h:1958 >#25 0x9571a8b in ?? () >#26 0x8070f3e in eval_instruction ( > pc=0x956dbc6 "\213\r0\207.\b¸:$©ö÷Ø\211A\034ÇD$\004") > at /home/david/Pike/7.6/src/interpret.c:1229 >#27 0x808ab04 in mega_apply (type=APPLY_STACK, args=8, arg1=0x0, arg2=0x0) > at /home/david/Pike/7.6/src/interpret.c:1982 >#28 0x808ad50 in f_call_function (args=8) > at /home/david/Pike/7.6/src/interpret.c:2053 >#29 0x285f890d in container_callback (this=0xa005f00, thisobj=0x8db2ed0, > v=0x98b4570, startc=0x8b0e5a0, cstartc=123, endc=0x8b0e5a0, >cendc=16534, > st=0x852ef70, cutstart=0x852ef7c, ccutstart=0x852ef80, >cutend=0x8b0e5a0, > ccutend=16541) at /home/david/Pike/7.6/src/modules/Parser/html.c:2735 >#30 0x285fabe0 in do_try_feed (this=0xa005f00, thisobj=0x8db2ed0, > st=0x852ef70, feed=0x852ef7c, finished=1, ignore_tag_cb=0) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3224 >#31 0x285fc942 in try_feed (finished=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3737 >---Type <return> to continue, or q <return> to quit--- >#32 0x285fd3de in html_finish (args=1) > at /home/david/Pike/7.6/src/modules/Parser/html.c:3932 >#33 0x8088554 in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x8db2ed0, > arg2=0xc) at /home/david/Pike/7.6/src/apply_low.h:214 >#34 0x8083668 in jump_opcode_F_CALL_OTHER (arg1=55) > at /home/david/Pike/7.6/src/interpret_functions.h:1958 >#35 0x9571a8b in ?? () >#36 0x8070f3e in eval_instruction (pc=0x8c99b06 "ÇD$\004\e") > at /home/david/Pike/7.6/src/interpret.c:1229 >#37 0x808ac41 in o_catch (pc=0x8c99b06 "ÇD$\004\e") > at /home/david/Pike/7.6/src/interpret.c:2027 >#38 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#39 0x8c99b00 in ?? () >#40 0x8070f3e in eval_instruction ( > pc=0x8b2f564 "¡0\207.\b\203@\034\017ÇD$\004\234") > at /home/david/Pike/7.6/src/interpret.c:1229 >#41 0x808ac41 in o_catch (pc=0x8b2f564 "¡0\207.\b\203@\034\017ÇD$\004\234") > at /home/david/Pike/7.6/src/interpret.c:2027 >#42 0x807c1f8 in jump_opcode_F_CATCH () > at /home/david/Pike/7.6/src/interpret_functions.h:1240 >#43 0x8b2f55e in ?? () >#44 0x8070f3e in eval_instruction ( >---Type <return> to continue, or q <return> to quit--- > pc=0x8b2f527 "\213\r0\207.\b¸Ù\nM÷÷Ø\211A\034Ç\004$\226") > at /home/david/Pike/7.6/src/interpret.c:1229 >#45 0x808ab04 in mega_apply (type=APPLY_STACK, args=2, arg1=0x0, arg2=0x0) > at /home/david/Pike/7.6/src/interpret.c:1982 >#46 0x808ad50 in f_call_function (args=2) > at /home/david/Pike/7.6/src/interpret.c:2053 >#47 0x8165cde in new_thread_func (data=0xbfbfef6c) > at /home/david/Pike/7.6/src/threads.c:868 >#48 0x282e71b4 in _thread_start () from /usr/lib/libc_r.so.4 >#49 0x0 in ?? () > > > > / Brevbäraren >

2 2

What about Judy
by Sten (Android) Eriksson (of Borg) ＠ Pike (-) developers forum 17 May '04

17 May '04

I just browsed a couple of old sweetcode.org articles and stumbled onto the "Judy functions" located at <http://judy.sourceforge.net/>. Snippet from sweetcode.org's description: "Judy is an implementation of a sorted associative array in C. All reasonable associative array implementations have O(log N) insert and lookup complexity, but the constant factor for Judy is very much smaller than other widely used implementations (several times faster than STL's "map" and twice as fast as SGI's "hash_map", in my trivial benchmarks)." This made me think of how beneficial it would be to Pike. There is a lot of doc's at the site, man pages, pdf-documents with both brief and in-depth descriptions and analysis. On associative arrays: <http://judy.sourceforge.net/application/judysl.pdf> On scalable hashing: <http://judy.sourceforge.net/application/Judy_hashing.pdf>

5 6

Pike 7.6.6 building problem
by David Gourdelier 15 May '04

15 May '04

Hello, When using the Pike tarball on ftp://pike.ida.liu.se/pub/pike/latest-stable/Pike-v7.6.6.tar.gz: checking for nettle_md5_init in -lnettle... no checking for md5_init in -lnettle... no Bundle nettle not available in /usr/local/src/Pike-v7.6.6/bundles. configure: error: Cannot compile --with-nettle without the Nettle library. It is highly recommended that you install a working Nettle library on your system as that will add features to Pike required by many applications. These features include ciphers, hash algorithms and random generators. If you know that you do not need cryptographic functions, you can re-run configure with the option --without-nettle instead. configure: error: /bin/bash -norc '/usr/local/src/Pike-v7.6.6/src/post_modules/Nettle/configure' failed for Nettle sed: can't read confdefs.h: No such file or directory configure: error: /bin/bash -norc '/usr/local/src/Pike-v7.6.6/src/post_modules/configure' failed for post_modules make: *** [configure] Error 1 david@camas:/usr/local/src/Pike-v7.6.6$ ls /usr/local/src/Pike-v7.6.6/bundles gmp.txt nettle-1.10.ptar.gz nettle.txt Shouldn't the file be named nettle-1.10.tar.gz instead of nettle-1.10.ptar.gz ? / David

4 4

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