Pike-devel January 2006

pike-devel@lists.lysator.liu.se

8 participants
33 discussions

mapping_rehash_backwards_{good,evil} rewrite
by Peter Bortas ＠ Pike developers forum 22 Jan '06

22 Jan '06

I see Jonas backported the mapping_rehash-rewrite grubba did in 7.7 to 7.6 and 7.4. This is probably good, but is there no testcase for the problem it should fix?

2 4

GTK2.Databox
by lance dillon 20 Jan '06

20 Jan '06

Another bug I found in 7.7 cvs, I think. The latest change (1.6) changes push_text() to ref_push_string(_STR()). Unfortunately, those were in a %{ %} block, which gets passed untranslated I believe. So, _STR() didn't get translated to the correct code, and GTK2.setup_gtk() returns with an undefined symbol: _STR. It should either get changed back to push_text(), or maybe to something else.

2 2

GTK2
by lance dillon 20 Jan '06

20 Jan '06

I think there is a type in gdkevent.pre in 7.7 (I don't have access to cvs from my work here, so I'm posting it here instead). The latest changes to gdkevent.pre on http://pike.ida.liu.se/development/cvs/pike.xml?between=2006-01-16&and=2006… At the bottom, case GDK_CLIENT_EVENT: - ref_push_string(s_data ); + ref_push_string(_STR("data ")); I think that should just be "data", not "data ".

2 1

patch to add affected_rows to Postgres
by Adam Montague 20 Jan '06

20 Jan '06

This adds an affected_rows() method to the Postgres module, which should behave just like the Mysql affected_rows() method. Also, should both of these methods have wrappers in the Sql.Mysql and Sql.Postgres modules so you don't need to call db->master_sql->affected_rows()? Adam

2 3

Fw: Protocols.SNMP.protocol()->readmsg hanging
by Adam Montague 19 Jan '06

19 Jan '06

Can this get all the way committed? The function args got changed, but the timeout still isn't actually used. Since UDP packets can go AWOL any time, you need to be able to set a timeout so you don't have your app waiting indefinately for UDP packets that will never arrive. Begin forwarded message: Date: Fri, 25 Nov 2005 17:16:14 -0500 From: Adam Montague <amontague(a)siriushosting.com> To: pikedevel <pike-devel(a)lists.lysator.liu.se> Subject: Protocols.SNMP.protocol()->readmsg hanging Protocols.SNMP.protocol()->readmsg waits forever trying to read from the socket. The problem is you can send out a request on a lossy link, then try to readmsg() it, and never get an answer, hanging your script. I've attached a tiny patch to add an optional int|void timeout to readmsg(). Adam

1 0

Null objects for postgresql (patch)
by Adam Montague 19 Jan '06

19 Jan '06

Here's a patch to add a Postgres.NULL object, and use it when results are NULL instead of returning "0". Adam

3 3

tracking lockups in Caudium on 7.6.50
by H.William Welliver III 16 Jan '06

16 Jan '06

A number of us who are running caudium on 7.6.50 have been experiencing what I'll describe as "lockups" on a pretty frequent basis. Normally, the watchdog will kill the process and restart things, but I wanted to figure out what was causing the problem. I managed to catch the hangup on my server a few minutes ago, and this is what I get: Describing all threads: Thread 1: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(2) Thread 2: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(3) Thread 3: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(4) Thread 4: _static_modules.Builtin()->thread_id: Thread.Thread(1)->backtrace() base_server/caudium.pike:3493: /opt/caudium/server/base_server/caudium ()->describe_all_threads() Stdio.File: Stdio.File("socket", "63.85.143.88 1198", 777 /* fd=103 */)->set_write_callback(Stdio.File("socket", "63.85.143.88 1198", 777 /* fd=103 */)$ /usr/local/pike/7.6.50/lib/modules/Stdio.pmod/module.pmod:1097: Stdio.File("socket", "63.85.143.88 1198", 777 /* fd=103 */)- >set_write_callback(SSL.ssl$ /usr/local/pike/7.6.50/lib/modules/SSL.pmod/sslfile.pike:1321: SSL.sslfile(Fd(103))->direct_write() /usr/local/pike/7.6.50/lib/modules/SSL.pmod/sslfile.pike:516: SSL.sslfile(Fd(103))->close(UNDEFINED,UNDEFINED) protocols/http.pike:812: /opt/caudium/server/protocols/ssl3()->end (0,UNDEFINED) _static_modules.Builtin()->Backend: Pike.Backend(0)->`()(0) /usr/local/pike/7.6.50/lib/master.pike:2703: master()->_main(({"/usr/ local/bin/pike","-DENABLE_THREADS","-DCAUDIUM","-DCAUDIUM_CACHE","- DROXEN","-Ietc/$ Thread 5: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(0) Thread 6: Thread.Thread(3351712).Queue: Thread.Thread(3351712).Queue(0)->wait (_static_modules.Builtin()->mutex_key()) /usr/local/pike/7.6.50/lib/modules/Thread.pmod:278: Thread.Thread (3351712).Queue(0)->read() base_server/caudium.pike:585: /opt/caudium/server/base_server/caudium ()->handler_thread(1) The hangup appears to be: Thread.Queue()->read() I also did a truss to see what the threads were up to, and here's what I got: bash-2.05$ sudo truss -p 26891 /1: ioctl(105, DP_POLL, 0xFFBFE8B8) (sleeping...) /2: lwp_park(0x00000000, 1) (sleeping...) /3: lwp_park(0x00000000, 0) (sleeping...) /4: lwp_park(0x00000000, 1) (sleeping...) /5: lwp_park(0x00000000, 0) (sleeping...) /6: lwp_park(0x00000000, 1) (sleeping...) /1: Received signal #5, SIGTRAP, in ioctl() [caught] This is Solaris 9/SPARC... any suggestions on how I might be able to troubleshoot the problem further? Bill

5 7

pike segfault test case
by Adam Montague 12 Jan '06

12 Jan '06

I created a module that makes pike segfault, and have narrowed it down to the simplest module that will reproduce the crash (its attached). Just doing indices(Crash) will make pike (7.6.50) segfault. Its just calling Module.some_program from a Module.some_function that causes the problem. If I change Crash.head_asplode() to call crash() instead of Crash.crash() then it stops segfaulting. But if Module.some_program is a regular class instead of a program variable pointed to a class, it also stops crashing. Like if I take out the "program crash = Crash.blah" and just make an actual crash.pike, then it won't segfault. Adam

2 1

GTK2 and 7.6.64
by lance dillon 11 Jan '06

11 Jan '06

So, I'm trying to backport GTK2 from 7.7 cvs to 7.6.64 (also 7.6.50), and it won't load the image_module in global.pre, INIT{}: INIT { #ifdef DYNAMIC_MODULE image_color_program = PIKE_MODULE_IMPORT(Image, image_color_program); if(!image_color_program) Pike_error("Could not load Image module.\n"); image_program = PIKE_MODULE_IMPORT(Image, image_program); if(!image_program) Pike_error("Could not load Image module.\n"); #endif } It apparently works with 7.7, but not 7.6. Did something change with dynamic module loading? What should I do instead? I noticed in some other modules it used SAFE_APPLY_MASTER() and a bunch of other statements...

2 2

Re: New distribution
by Martin Nilsson (Opera) ＠ Pike (-) developers forum 11 Jan '06

11 Jan '06

I got stuck at looking at SSL Certificate bugs. I guess you can start with -DSSL3_DEBUG to get debug data from SSL if you want. I think you need to have a non-dumped Pike for that to work.

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 January 2006