Pike-devel August 2004

pike-devel@lists.lysator.liu.se

12 participants
35 discussions

managing comport settings in linux
by Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum 13 Mar '26

13 Mar '26

Not a good idea; the design philosophy of Pike is that Pike-level code should never be able to cause memory corruption at C-level. With ioctls there's no way to know what data a specific ioctl wants without reading the documentation for that specific ioctl for that specific OS. ioctls and fcntls are a way for device handlers to hook in APIs that aren't standard across all filedescriptors. / Henrik Grubbström (Lysator) Previous text: >2004-08-17 13:32: >Subject: managing comport settings in linux >-------------------------------------------------------------------- >What would be nice, is a way to define ioctl methods in >Pike. Perhaps something like > >object i = Stdio.IOCTL(4242 /* request_id */ ); >i->add_int_parameter(); >i->add_string_parameter(); >i->set_return_type(STRING); > >string ret = i(fd, 1, "somestring"); > > >That ought to be possible, or..? > > / Marcus Agehall (PacketFront) >

3 2

full MySQL 4.x support. or pike roadmap
by thomas.gusenleitner＠com-bet.com ＠ Pike developers forum 01 Mar '26

01 Mar '26

HI to all! mysql 4.x support works only with a mysql CFLAGS=-DUSE_OLD_FUNCTIONS is this correct ? are there plans to make a full 4.x support ? bye, thomas

4 4

array.c
by Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum 10 Sep '04

10 Sep '04

Would it be possible and make sense to have the structures that supports over-allocation (such as arrays) to always use full malloc "quanta"?

5 8

oracle problem with columns of type DATE
by Michael J. Stenitzer ＠ Pike developers forum 31 Aug '04

31 Aug '04

as already posted on the roxen list last week, there is still a problem with oracle support in "recent" pike (7.4 and up, i guess) and therefore its not possible using roxen 4 with oracle. (yes i have upgraded to Pike v7.4 release 139, which fixed an oracle bug). i have eg. a table 'technologien' Name Null? Type ------------------------------- -------- ---- TECH_VALUE NOT NULL VARCHAR2(120) TECH_DESC VARCHAR2(1000) CR_DATE DATE CR_BY VARCHAR2(10) LANG_LANG_ID NOT NULL NUMBER(10) MOD_DATE DATE MOD_BY VARCHAR2(10) TECH_TYP_TECH_TYP_ID NOT NULL NUMBER(10) TECH_ID NOT NULL NUMBER(10) if i make a query, eg. SELECT * FROM technologien i get an error > Cast failed, wanted string, got int according to the backtrace it seems that colums of type DATE make a problem with the argument type in compat_convert(). all other types (at least those we use) do work fine. Pike backtrace * /usr/local/pike/7.4.139/lib/modules/Oracle.pmod:60 Sql.oracle()->big_query()->compat_convert(30-NOV-99) * /usr/local/pike/7.4.139/lib/modules/Oracle.pmod:68 Sql.oracle()->big_query()->fetch_row() * /usr/local/pike/7.4.139/lib/modules/Sql.pmod/sql_result.pike:118 (version 1.11) Sql.sql_result()->fetch_row() * modules/database/sqltag.pike:294 (version 1.102) RoxenModule(nw-test/sqltag#0)->SqlEmitResponse()->really_get_row() * base_server/emit_object.pike:61 RoxenModule(nw-test/sqltag#0)->SqlEmitResponse()->get_row() [...]

2 1

pike modules
by Kaos 30 Aug '04

30 Aug '04

What is the difference with the two following examples for bar? 1) Foo.pmod/bar.pike 2) Foo.pmod/bar.pmod bar is a file in both cases, and Foo is somewhere where pike finds it. And asking about modules, pike --help=environment mentions a program path. When is the program path used? For what? Thanks!

4 11

More testing of Shuffler
by David Gourdelier 28 Aug '04

28 Aug '04

Hi, I discover another crash with the Shuffler. Here is a test case: #!/usr/local/bin/pike void shuffle_filename() { object shuffler; object shuffle; shuffler = Shuffler.Shuffler(); object stdin = Stdio.File(); mapping options = ([ "stdin": stdin, "stdout": Stdio.stdout->pipe() ]); stdin = stdin->pipe(); Process.create_process(({ "/bin/ls" }), options); shuffle = shuffler->shuffle(stdin); // don't crash if i put data in the string //string data = "foobarzonk"; // crash if empty string string data = ""; shuffle->add_source(data); function foo = lambda() { destruct(stdin);}; // doesn't crash if i don't put write write("crash me! %O\n", 1); shuffle->set_done_callback(foo); shuffle->start(); } int main(int argc, array argv) { shuffle_filename(); return -1; } With Pike 7.6 it leads to the backtrace: #0 0x0832d200 in type_stack () #1 0x4001cfdd in __send_more_callback (t=0x83be188, amount=8192) at Shuffler.cmod:445 #2 0x4001b883 in _send_more (t=0x1) at Shuffler.cmod:291 #3 0x080cf653 in low_backend_once (me=0x83c2398, timeout=0xbffff3d8) at backend.cmod:2581 #4 0x080cfb9f in f_Backend_cq__backtick_28_29 (args=-1) at backend.cmod:2828 #5 0x0809c90a in low_mega_apply (type=APPLY_SVALUE, args=1, arg1=0x83c89fc, arg2=0x0) at apply_low.h:214 #6 0x08091be7 in eval_instruction_without_debug ( pc=0x841f7a5 "Q\031Q¶1XõÿÿÿJ(OÁR'(¿\227köÿÿÿQ\031Q¶1Q\031Q¶1XØÿÿÿ\001\001!l'") at interpret_functions.h:1936 #7 0x0809ee1b in o_catch ( pc=0x841f7a0 "Q\031Q¶1Q\031Q¶1XõÿÿÿJ(OÁR'(¿\227köÿÿÿQ\031Q¶1Q\031Q¶1XØÿÿÿ\001\001!l'") at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2053 #8 0x0808e029 in eval_instruction_without_debug (pc=0x841f79c "\023") at interpret_functions.h:1236 #9 0x0809ec28 in mega_apply (type=APPLY_STACK, args=0, arg1=0x0, arg2=0x0) at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2012 #10 0x080a0a10 in apply (o=0x83b9b10, fun=0x8285d4c "_main", args=0) at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2392 #11 0x08130c6b in main (argc=2, argv=0xbffffc34) at /home/david/current-projects/pike/Pike/7.6/src/main.c:839 But sometime I also get this one (from a similar program with pipe and process.create_process and still with empty string as source): #0 0x00000040 in ?? () #1 0x407098be in _set_callbacks (t=0x8ae1c98) at Shuffler.cmod:298 #2 0x0809c90a in low_mega_apply (type=APPLY_LOW, args=0, arg1=0x83c8a7c, arg2=0xc) at apply_low.h:214 #3 0x080926e6 in eval_instruction_without_debug ( pc=0x8add484 "}\003\001Ä\vÇ\fE\001\035\005\005\a\026l='\001\035\006B\233\006\001\026\nd\017") at interpret_functions.h:1995 #4 0x0809ee1b in o_catch (pc=0x86fc592 "!\033Í") at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2053 #5 0x0808e029 in eval_instruction_without_debug (pc=0x86fc58e "\r") at interpret_functions.h:1236 #6 0x0809ee1b in o_catch (pc=0x8632d48 "! ¾-E\001e\035") at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2053 #7 0x0808e029 in eval_instruction_without_debug (pc=0x8632d44 "{") at interpret_functions.h:1236 #8 0x0809ec28 in mega_apply (type=145629520, args=145629520, arg1=0x8ae2150, arg2=0x8ae2150) at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2012 #9 0x0809eee5 in f_call_function (args=145629520) at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2076 #10 0x08184044 in new_thread_func (data=0xbfffef70) at /home/david/current-projects/pike/Pike/7.6/src/threads.c:868 #11 0x4007ae51 in pthread_start_thread () from /lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #12 0x4007aecf in pthread_start_thread_event () from /lib/libpthread.so.0 #13 0x401ca6ca in clone () from /lib/libc.so.6 / David

2 1

Shuffler can't handle big file
by David Gourdelier 28 Aug '04

28 Aug '04

Hi, Here is another bug with the Shuffler. If I create a big file with the Shuffler (more than 2.1GB) and test this program: #!/usr/local/bin/pike Stdio.File dest_fd; void shuffle_filename(string filename) { object shuffler; object shuffle; shuffler = Shuffler.Shuffler(); shuffle = shuffler->shuffle(dest_fd); shuffle->set_done_callback(lambda() { destruct(dest_fd);}); shuffle->add_source(Stdio.File(filename, "r")); shuffle->start(); } int main(int argc, array argv) { object port = Stdio.Port(8080); dest_fd = port->accept(); shuffle_filename(argv[1]); return -1; } Then if call this program with a 2.1GB file as argument and connect to port 8080, I get no data (while I should get 2.1GB of data) and the done callback is called immediatly. The same program works perfectly for files with "normal" size. The limit seem to be just above 2.0GB. Tested on Linux 2.4 with reseirfs and Pike 7.6 CVS. / David

3 13

Re: Segfault in backend
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 27 Aug '04

27 Aug '04

> /home/david/current-projects/pike/Pike/7.6/src/backend.cmod:3396: Fatal > error: > Mixing old and new style backend interfaces for fd 23. The immediate problem here is due to mixing fd's between the new callback system that Stdio.Fd uses and the old one used by the shuffler in 7.6. I could fix the compat code to cope somewhat with it, but I suspect that could cause more insidious bugs later instead. The real issue here is the question of who "governs" the fd, the Stdio.Fd object or the shuffler object, and how the fd is "handed over" in a controlled way. This is what Stephen has fixed properly in 7.7. So I think the best way is to backport that to 7.6. / Martin Stjernholm, Roxen IS Previous text: >2004-08-23 22:31: >Subject: Re: Segfault in backend >-------------------------------------------------------------------- >Martin Stjernholm, Roxen IS @ Pike developers forum wrote: >> It'd be useful to enable rtldebug if you don't have it already. >> There'd probably also be some useful debug printout if you uncomment >> the #define POLL_DEBUG line in backend.cmod. Lastly, stack frames got >> to be missing from that backtrace, so please don't use >> -fomit-frame-pointer or whatever optimizations you have that cause >> that. >> >> This bug aside, the Shuffler module really ought to move away from the >> old compat callback interface and use fd_callback_box directly. Didn't >> Stephen fix that recently? > >OK, here are the infos, I hope it'll be usefull: > >Program received signal SIGABRT, Aborted. >[Switching to Thread 16386 (LWP 23112)] >0x4011c741 in kill () from /lib/libc.so.6 >(gdb) bt >#0 0x4011c741 in kill () from /lib/libc.so.6 >#1 0x4007d771 in pthread_kill () from /lib/libpthread.so.0 >#2 0x4007da7b in raise () from /lib/libpthread.so.0 >#3 0x4011c4d4 in raise () from /lib/libc.so.6 >#4 0x4011da08 in abort () from /lib/libc.so.6 >#5 0x080eea99 in debug_fatal (fmt=0x854f140 "§") > at /home/david/current-projects/pike/Pike/7.6/src/error.c:438 >#6 0x080d1b04 in set_read_callback (fd=23, cb=0, data=0x0) at >backend.cmod:3396 >#7 0x40709f44 in f_Shuffle_create (args=4) at Shuffler.cmod:566 >#8 0x0809c87a in low_mega_apply (type=APPLY_LOW, args=4, arg1=0x83c93d0, > arg2=0xb) at apply_low.h:214 >#9 0x0809eb5e in mega_apply (type=APPLY_STACK, args=0, arg1=0x0, arg2=0x0) > at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:1996 >#10 0x0813d41f in call_pike_initializers (o=0x878ae88, args=0) > at /home/david/current-projects/pike/Pike/7.6/src/object.c:332 >#11 0x0813d6aa in debug_clone_object (p=0x40082e74, args=0) > at /home/david/current-projects/pike/Pike/7.6/src/object.c:358 >#12 0x4070b1e4 in f_Shuffler_shuffle (args=0) at Shuffler.cmod:837 >#13 0x0809c87a in low_mega_apply (type=APPLY_LOW, args=1, arg1=0x83c942c, > arg2=0x8) at apply_low.h:214 >#14 0x080922e6 in eval_instruction_without_debug (pc=0x86f44a2 >"L3}\002\002]") > at interpret_functions.h:1941 >#15 0x0809ed8b in o_catch (pc=0x8632f4e "!\236¾,E\001e\035") > at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2046 >#16 0x0808df99 in eval_instruction_without_debug (pc=0x8632f4a "{") > at interpret_functions.h:1236 >#17 0x0809eb98 in mega_apply (type=APPLY_STACK, args=0, arg1=0x0, arg2=0x0) > at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2005 >#18 0x0809ee55 in f_call_function (args=0) > at /home/david/current-projects/pike/Pike/7.6/src/interpret.c:2069 >#19 0x081846a4 in new_thread_func (data=0xbfffefe0) > at /home/david/current-projects/pike/Pike/7.6/src/threads.c:868 >#20 0x4007ae51 in pthread_start_thread () from /lib/libpthread.so.0 >#21 0x4007aecf in pthread_start_thread_event () from /lib/libpthread.so.0 >#22 0x401ca6ca in clone () from /lib/libc.so.6 > >And the console: > >BACKEND: copy_poll_set() from->num_in_poll=5 >[23109]BACKEND[0]: Doing poll on fds: >[23109]BACKEND[0]: fd 8: read : 0x0041 >[23109]BACKEND[0]: fd 14: read : 0x0041 >[23109]BACKEND[0]: fd 16: read : 0x0041 >[23109]BACKEND[0]: fd 19: read : 0x0041 >[23109]BACKEND[0]: fd 20: read : 0x0041 >[23109]BACKEND[0]: poll(0x8649890, 5, 6164)... => 1 >[23112]BACKEND[unhooked box]: unhook_fd_callback_box: fd -1, object >0x878aed0 >fd:8 events:0x0041 >[23109]BACKEND[0]: POLLRDNORM|POLLIN on 8 >[23109]BACKEND[0]: read_callback(8, (nil)) >fd:14 events:0x0000 >fd:16 events:0x0000 >fd:19 events:0x0000 >fd:20 events:0x0000 >[23112]BACKEND[unhooked box]: change_fd_for_box: fd from 24 to -1 >[23109]BACKEND[unhooked box]: unhook_fd_callback_box: fd -1, object >0x878ae70 >[23109]BACKEND[unhooked box]: change_fd_for_box: fd from 24 to 24 >[23109]BACKEND[unhooked box]: unhook_fd_callback_box: fd -1, object >0x878ae10 >[23109]BACKEND[unhooked box]: unhook_fd_callback_box: fd -1, object >0x878adf8 >[23112]BACKEND[unhooked box]: unhook_fd_callback_box: fd -1, object >0x878aea0 >[23112]BACKEND[0]: set_read_callback (23, (nil), (nil)) >/home/david/current-projects/pike/Pike/7.6/src/backend.cmod:3396: Fatal >error: >Mixing old and new style backend interfaces for fd 23. >Backtrace at time of fatal: >object(src/dynamic_load.c:565).Shuffle: > >object(src/post_modules/Shuffler/Shuffler.cmod:877)->create(object(/usr/loca > >l/pike/7.6.13/lib/modules/Stdio.pmod/module.pmod:109),object(src/post_module > s/Shuffler/Shuffler.cmod:641),0,0) > >object(src/dynamic_load.c:565).Shuffler: > object(src/post_modules/Shuffler/Shuffler.cmod:641)->shuffle() > >protocols/http.pike:77: > >object(/usr/local/caudium_1_3/caudium/server/protocols/http.pike)->setup_pip > >e(@0=object(/usr/local/pike/7.6.13/lib/modules/Stdio.pmod/module.pmod:109)) >protocols/http.pike:1545: > >object(/usr/local/caudium_1_3/caudium/server/protocols/http.pike)->send_resu > lt(0) > >protocols/http.pike:1639: > >object(/usr/local/caudium_1_3/caudium/server/protocols/http.pike)->handle_re > quest() > >base_server/caudium.pike:554: > >object(/usr/local/caudium_1_3/caudium/server/base_server/caudium.pike)->hand > ler_thread(0) > > => 0 >BACKEND: copy_poll_set() from->num_in_poll=1 >[23107]BACKEND[0]: Doing poll on fds: >[23107]BACKEND[0]: fd 3: read : 0x0041 >[23107]BACKEND[0]: poll(0x83f2ef8, 1, 1999)... => 0 >BACKEND: copy_poll_set() from->num_in_poll=1 >[23107]BACKEND[0]: Doing poll on fds: >[23107]BACKEND[0]: fd 3: read : 0x0041 > > > / Brevbäraren >

4 7

nice-to-have-function
by Fredrik (Naranek) Hubinette (T minus 2 weeks) ＠ Pike (-) developers forum 26 Aug '04

26 Aug '04

Image.Image->apply_matrix is not always very useful... I'm a little busy myself, otherwise I would provide a patch, my suggestion is that someone adds a function that does this to Image.Image: Image.Image convol(Image.Image i, array(array(array(array(float)))) foo) { Image.Image ret; array(array(array(array(int)))) foo1= ( array(array(array(array(int)))) ) (foo[*][*][*][*]*100000); for(int x=0;x<3;x++) { array(int) c1=({ 0,0,0 }); c1[x]=255; array(array(array(int))) foo2=foo1[*][*][x]; for(int y=0;y<3;y++) { array(array(int)) foo3=foo2[*][*][y]; int sum=`+(0, @ foo3*({})); array(int) c2=({ 0,0,0 }); c2[x]=255; Image.Image tmp; tmp=i->gray(@c1)->apply_matrix(foo3,0,0,0, sum?100000.0/sum:1.0)*c2; if(ret) ret+=tmp; else ret=tmp; } } return ret; } I've need a function like this twice now, so I think it would be useful. Also, the implementation above is grossly inefficient.. If anybody knows a faster way to do the same thing with the currently available Image operations, let me know. Possible extentions to this function: o Add the results to an image to avoid the clipping that would occur if you did the addition afterwards. o Add x-stride and y-stride to allow it to compute only every x:th and y:th pixel to allow scaling in the same step. (Is it even possible to scale an image without averaging right now?)

6 12

Re: There's no master to handle the error. Dumping it raw...
by Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum 26 Aug '04

26 Aug '04

Since it breaks in post modules, you should already have a (broken) pike compiled. Try to run bin/pike --gdb and see if you get the error. / Martin Nilsson (DivX Networks) Previous text: >2004-08-26 09:24: >Subject: Re: There's no master to handle the error. Dumping it raw... >-------------------------------------------------------------------- >Hi martin, > >> Have you ever completed a compile manually on that machine? The >> intended >> use for xenofarm is to maintain code quality, not achieve it. > >I have tryed... Had same problems as on pikefarm and saw that machine >code seg11 the non installed pike... > >So I have compiled without it and the result was mutch better. > >But the no master error came out... :) > >Ok since this is an ultra 5 and that the compilation takes about one >hour, what is the best way to find and fix that bug ? > >/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 > > > > / Brevbäraren >

1 0

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 August 2004