Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3040 discussions

Start a nNew thread

Status of pike-www.lysator.liu.se ?
by Stephen R. van den Berg 12 Mar '21

12 Mar '21

Server crashed? -- Stephen.

2 1

Timezone.Runtime_timezone_compiler memory footprint
by Stephen R. van den Berg 11 Mar '21

11 Mar '21

I have been eliminating some memory leaks from the Shuffler, while running my SPike webserver. Things seem to have stabilised now. However, when inspecting the memory footprint, I see the dump at the bottom of this mail. Now, in the grand scheme of things, 850.4kB might not be a lot, but I'm still wondering why it is still being occupied. I mean, I get that because I've been accessing timezones somewhere (though I'm still wondering where exactly), it needs to compile the current timezone. However, after having done that, the timezone compiler should have been freed, and it appears that it is not. Any clues as to why this is happening? ---------------------------------------------------------------------- Object Clones Memory Loc ---------------------------------------------------------------------- imezone.Runtime_timezone_compiler 1 850.4k Timezone.pmod:541 s.Builtin()->multi_string_replace 32 282.1k builtin.cmod:4347 Runtime_timezone_compiler()->Zone 386 151.7k Timezone.pmod:1065 Sql.pgsql_util.conxiin 1 96.5k pgsql_util.pmod:404 Runtime_timezone_compiler()->Rule 139 86.0k Timezone.pmod:811 master()->dirnode 29 81.6k master.pike:2574 MIME.ext_to_media_type 1 65.4k ext_to_media_type.pmod:1659 master 1 47.9k master.pike Standards.ASN1.Types.Identifier 200 42.8k Types.pmod:626 master()->joinnode 30 36.7k master.pike:3013 Parser._parser.HTML 3 24.8k parser.c:196 _static_modules.Builtin()->Search 1 16.1k pike_search.c:188 piler()->__class_66275_0_line_791 1 15.5k Timezone.pmod:792 Standards.PKCS.Identifiers 1 10.0k Identifiers.pmod Calendar.Language.cEN 1 6.3k Language.pmod:525 /main()->SPike 1 5.5k spike:64 Nettle.BufferedCipher()->_Buffer 49 4.2k cipher.cmod:533 sites.pmod 1 4.1k sites.pmod managebackground.pmod 1 3.6k managebackground.pmod Sql.pgsql_util.proxy 1 3.2k pgsql_util.pmod:1965 .Builtin()->single_string_replace 18 2.3k builtin.cmod:4507 Stdio.FILE 4 2.3k module.pmod:1927 Crypto.DH.Parameters 17 2.3k DH.pmod:71 TP.Server.Request()->OutputBuffer 1 2.2k Request.pike:908 Regexp.SimpleRegexp 10 2.2k Regexp.pmod:48 Sql.pgsql_util 1 2.1k pgsql_util.pmod _static_modules._Stdio()->Buffer 4 2.1k buffer.cmod:77 _static_modules.Builtin()->mutex 14 1.9k threads.c:4690 es.Builtin()->DefaultBackendClass 4 1.8k backend.cmod:3253 Pike.Lazy 13 1.8k Lazy.pmod:19 Calendar.ISO 2 1.5k ISO.pmod:11 atic_modules.Builtin()->thread_id 5 1.4k threads.c:4816 /main()->SPike()->regex 12 1.4k spike:459 /main()->SPike()->singleresponse 2 1.2k spike:578 /main()->SPike()->fromfilesystem 7 1.2k spike:610 Thread.Queue 3 1.1k Thread.pmod:241 Stdio.File 2 1.1k module.pmod:188 _static_modules.Gmp()->mpz 4 0.9k mpz_glue.c:2476 Val.Inet 9 0.9k Inet.pike les.Builtin()->Backend()->CallOut 4 0.8k backend.cmod:509 atic_modules.Builtin()->condition 6 0.8k threads.c:4766 _static_modules._Stdio()->Fd 3 0.8k file.cmod:282 Nettle.BlockCipher()->_IGE 7 0.7k cipher.cmod:1606 Nettle.BlockCipher()->_PCBC 7 0.7k cipher.cmod:1450 Nettle.BlockCipher()->_CBC 7 0.7k cipher.cmod:1124 Nettle.BlockCipher()->_OFB 7 0.7k cipher.cmod:3196 Nettle.BlockCipher()->_ABC 7 0.7k cipher.cmod:1987 Nettle.BlockCipher()->_CFB 7 0.7k cipher.cmod:2367 Standards.ASN1.Types.MetaExplicit 6 0.7k Types.pmod:1071 Nettle.BlockCipher()->_CTR 7 0.6k cipher.cmod:2825 odules.Builtin()->pike_trampoline 6 0.5k builtin.cmod:7330 Calendar.Rule.Timezone 5 0.5k Rule.pmod:19 destructed 0 0.0k - ---------------------------------------------------------------------- -- Stephen.

2 1

BA_INIT_ALIGNED
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 08 Mar '21

08 Mar '21

In August 2013, Arne added support for alignment to block_allocator. In doing so, he also introduced a dependency on memalign/posix_memalign. I was planning on rewriting this support to work without memalign, but then I started looking for places which _use_ this functionality, and found none. Pike seems to build just fine without it. If it's dead code, maybe it's better to just remove it?

2 2

Proposal: Built-ins for generators
by Chris Angelico 07 Mar '21

07 Mar '21

A generator function will, when called, return a generator state function. (Are there better terms for these?) It'd be extremely helpful to have a couple of built-in functions to give some info about them. 1) generatorp continue int gen() {continue return 1; return 2;} generatorp(gen) ==> 1 generatorp(gen()) ==> 2 Alternatively, since these are both functions, functionp could return 1 for regular functions, 2 for continue functions, and 3 for continuation functions, but I think a separate generatorp function is better. 2) Function.gen_active function g = gen(); gen_active(g) ==> -1 (Function.NOT_STARTED) g() gen_active(g) ==> 1 (Function.ACTIVE) g() gen_active(g) ==> 0 (Function.ENDED) Once a generator state function is in the ENDED state, calling it will always return UNDEFINED. Having this function available will allow the state to be recognized without an additional call. Open to discussion/bikeshedding on the details, but these functions would be extremely helpful in building an asynchronous system using generators. Opinions? ChrisA

1 0

Re: Possible over-optimization with 'continue return'
by Chris Angelico 05 Mar '21

05 Mar '21

On Sat, Mar 6, 2021 at 7:59 AM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > > Playing around with generators, and have come across a strange oddity. > > This code works fine: > [...] > > But remove any of the 'if' guards, and the function terminates prematurely. > > > > continue int gen(int x) > > { > > if (x == 1) continue return 1; > > continue return 2; > > if (x == 1) continue return 3; > > return 4; > > } > > > > This will print out 1, 2, 0, and then halt. It appears that perhaps an > > unconditional 'continue return' causes subsequent code to be > > eliminated as if following a hard 'return' statement? > > Indeed. Looks like it is probably a bug in treeopt, where there's > likely some rule that doesn't know about continue return. Thanks for the pointer! Found it, I think. I've pushed it to the branch rosuav/deoptimize-continue-return - would appreciate a second opinion on this! -F_COMMA_EXPR(0 = F_COMMA_EXPR(*, F_RETURN), +[!($$->tree_info & OPT_CASE)]): +// Code after a return statement can be eliminated, as long as +// it's not a 'continue return' statement. +F_COMMA_EXPR(0 = F_COMMA_EXPR(*, F_RETURN(*, F_CONSTANT[!($$->u.sval.u.integer)])), + +[!($$->tree_info & OPT_CASE)]): $0; ChrisA

1 0

Possible over-optimization with 'continue return'
by Chris Angelico 05 Mar '21

05 Mar '21

Playing around with generators, and have come across a strange oddity. This code works fine: continue int gen(int x) { if (x == 1) continue return 1; if (x == 1) continue return 2; if (x == 1) continue return 3; return 4; } int main() { function foo = gen(1); while (1) { int i = foo(); if (undefinedp(i)) break; write("%d\n", i); } } But remove any of the 'if' guards, and the function terminates prematurely. continue int gen(int x) { if (x == 1) continue return 1; continue return 2; if (x == 1) continue return 3; return 4; } This will print out 1, 2, 0, and then halt. It appears that perhaps an unconditional 'continue return' causes subsequent code to be eliminated as if following a hard 'return' statement? ChrisA

2 1

Changing the DefaultBackend ?
by Stephen R. van den Berg 23 Feb '21

23 Feb '21

How does one change the DefaultBackend in Pike? I tried something like: int main(int argc, array(string) argv) { Pike.DefaultBackend = Pike.PollDeviceBackend(); return -1; } Which results in: Illegal lvalue. -- Stephen.

1 0

Disabling optimizations
by H William Welliver 18 Feb '21

18 Feb '21

As I’m working on the debugger, I find myself spending a lot of time scratching my head only to realize that pike has, in the course of its many brilliant optimizations, decided to execute code in a way I’m not expecting. Is there a way to disable optimizations so that the flow of code is a little bit closer to what’s in the source? I suspect this would be helpful for users trying to to use a debugger as well.

1 0

Questions about LiveBacktraceFrame
by H William Welliver 18 Feb '21

18 Feb '21

Hello all- Given the following bttest.pike on a recent pike master, I get some unexpected behavior. int main(int argc, array argv) { mixed bt = backtrace(1)[(int)argv[1]]; write("%O\n", bt->fun); for(int i = 0; i < bt->num_locals; i++) write("%O: %O\n", bt->get_local_name(i), bt->get_local(i)); return 0; } Run 1: bin/pike bttest 0 master()->_main "debugger": ({ /* 5 elements */ "/Users/hww3/pikedbg/build/darwin-18.7.0-x86_64/pike", "-DPRECOMPILED_SEARCH_MORE", "-m/Users/hww3/pikedbg/build/darwin-18.7.0-x86_64/master.pike", "bttest", "0" }) "argv": ({ /* 2 elements */ "/Users/hww3/pikedbg/bttest", "0" }) "debug": 0 "trace": 0 "run_tool": 0 "tmp": Getopt "postparseaction": 0 "parts": 0 "i": master()->Version(8.1) "have_debugger": 0 "debugger_wait": 0 "debugger_signal": 0 "debugger_port": 0 "t": /Users/hww3/pikedbg/bttest "err": 0 "script": /Users/hww3/pikedbg/bttest() "first_arg": int 0: 0 0: 0 0: 0 0: 0 0: 0 0: 0 0: 0 0: 0 Run 2: bin/pike bttest 1 /main()->main 0: 2 0: ({ /* 2 elements */ "/Users/hww3/pikedbg/bttest", "1" }) "bt": _static_modules.Builtin()->LiveBacktraceFrame() 0: 3 Some questions: 1. It seems logical to me that out-of-scope locals have a local name of zero. However, it’s strange to me that function arguments, while treated as locals, don’t have names (see both examples). 2. It’s also strange that the for-loop variable ‘i' doesn’t have a name. If I move the definition of ‘i’ ahead of the for loop, it does have a name. 3. The value of “debugger” from the first listing looks more like the value of orig_argv, which doesn’t appear elsewhere in the locals list. I also don’t seem to have a variable called “debugger” in my definition of “_main” (but there is a variable called “debugger” in the containing (master) object. Am I doing something wrong in my use of these frames? I get similar strange behavior in the debugger itself, when the thread of the backtrace I’m examining is paused. Bill

1 0

Need assistance decoding a gc fatal
by H William Welliver 13 Feb '21

13 Feb '21

I’ve been working on updating/enhancing the debugger concept code and I’ve run into a situation where a gc fatal report is generated. I’m not exactly sure what it’s trying to say, as I /think/ the data all makes sense (though I’m unclear what 2+0 internal refs vs 2 refs might mean. The pike in question is based on master from quite a while ago. I tried merging current master (which itself was a surprisingly easy task), but pike fails to compile due to typechecker errors. I tried building straight from master, but the build similarly fails with --with-debug and without that, pike compiles but fails to start. I’m hoping that doesn’t prevent coming up with an explanation for the problem. I believe the “thing” in question is the main program, which comes from a file called file.pike. I’ve created a breakpoint object( for a line in this program), which is a PIKECLASS defined in _Debug/debug.cmod. The breakpoint object /does/ hold a reference to the program containing the breakpoint, but at this point, the breakpoint object hasn’t been destroyed. Can anyone detect a problem from this report? Bill ---CUT HERE --- /Users/hww3/pikedbg/src/gc.c:1938: GC fatal: Thing is getting more internal refs (2 + 0) than refs (2). (Could be an extra free somewhere, or a pointer might have been checked more than once.) **Block: 0x10dd303f0 Type: program Refs: 2 **Got gc marker at 0x10dd303f0: flags=0x00002 refs=2 weak=0 xrefs=0 saved=2 frame=0x0 **Program id: 65669, flags: f, parent id: -1 **Location: /Users/hww3/pikedbg/file.pike:0 **Identifiers: ** 0 fun: name: main addr: 0x24 ** 1 fun: use name: f addr: 0x360 ******************* **Looking for references to 0x10dd303f0: ***One ref found as mapping index. -> from mapping 0x7faf328004d0 offset -8362904 **In index program(/Users/hww3/pikedbg/file.pike) **Block: 0x7faf328004d0 Type: mapping Refs: 1 Refs=1, next=0x7faf32800490, prev=0x7faf32800510, flags=0x0, size=33, hashsize=16 Indices type field = program Values type field = string ([ /* 33 elements */ master: "/master", object_program(Getopt): "/Users/hww3/pikedbg/lib/modules/Getopt.pmod", /main: "/main", object_program(Debug): "/Users/hww3/pikedbg/lib/modules/Debug.pmod/module.pmod", object_program(Debug.Debugger): "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/module.pmod", Debug.Debugger.Breakpoint: "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/Breakpoint.pike", Debug.Debugger.DebugServer: "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/DebugServer.pike", object_program(Debug.Debugger.DebugAdapterProtocol): "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/DebugAdapterProtocol.pmod", - - - trimmed for brevity ]) ******************* ----------end------------ ***One ref found as mapping value. -> from mapping 0x7faf328003d0 offset 537720 **In value with index "/main" **Block: 0x7faf328003d0 Type: mapping Refs: 1 Refs=1, next=0x7faf32800290, prev=0x7faf32800350, flags=0x0, size=33, hashsize=16 Indices type field = string Values type field = program ([ /* 33 elements */ "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/Breakpoint.pike": Debug.Debugger.Breakpoint, "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/DebugAdapterProtocol.pmod": object_program(Debug.Debugger.DebugAdapterProtocol), "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/DebugServer.pike": Debug.Debugger.DebugServer, "/Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/module.pmod": object_program(Debug.Debugger), "/Users/hww3/pikedbg/lib/modules/Debug.pmod/module.pmod": object_program(Debug), "/Users/hww3/pikedbg/lib/modules/Pike.pmod/module.pmod": object_program(Pike), - - - trimmed for brevity "/main": /main, "/master": master ]) ******************* ----------end------------ ***One ref found. -> from object 0x7faf3286eaa0 offset 10033200 **In storage for inherit 0 **In variable prog **In storage for inherit 1 (debug_breakpoint) **Block: 0x7faf3286eaa0 Type: object Refs: 1 **Got gc marker at 0x7faf3286eaa0: flags=0x00002 refs=1 weak=0 xrefs=0 saved=1 frame=0x0 **Program id: 65699 **Object variables: ** === In inherit "debug_breakpoint", program 65626: ** rtt: program name: prog off: 0 value: program(/Users/hww3/pikedbg/file.pike) ** rtt: string name: programs_fname off: 8 value: "/Users/hww3/pikedbg/file.pike" ** rtt: string name: real_path off: 16 value: "/Users/hww3/pikedbg/file.pike" ** rtt: string name: within_fname off: 24 value: "/Users/hww3/pikedbg/file.pike" ** rtt: int name: line_number off: 32 value: 18 ** rtt: int name: enabled off: 40 value: 1 ** rtt: int name: want_enabled off: 48 value: 0 **Describing program 0x10dd33000 of object: **Got gc marker at 0x10dd33000: flags=0x00002 refs=4 weak=0 xrefs=0 saved=4 frame=0x0 **Program id: 65699, flags: 202f, parent id: -1 **The program was written in C. **Location: /Users/hww3/pikedbg/lib/modules/Debug.pmod/Debugger.pmod/Breakpoint.pike:0 **There is no parent (any longer?) ******************* ----------end------------ ***One ref found as the program of an object. **Block: 0x7faf3286ea50 Type: object Refs: 5 **Program id: 65669 **Object variables: ** (none) **Describing program 0x10dd303f0 of object: **Got gc marker at 0x10dd303f0: flags=0x00002 refs=2 weak=0 xrefs=0 saved=2 frame=0x0 **Program id: 65669, flags: f, parent id: -1 **Location: /Users/hww3/pikedbg/file.pike:0 **There is no parent (any longer?) ******************* ----------end------------ ***One ref found in current_program in frame on stack. **Block: 0x7faf32821b38 Type: pike_frame Refs: 1 **Function f at /Users/hww3/pikedbg/file.pike:14 ******************* ----------end------------ ***One ref found in current_program in frame on stack. **Block: 0x7faf32821aa0 Type: pike_frame Refs: 1 **Function main at /Users/hww3/pikedbg/file.pike:2 ******************* ----------end------------ ***One ref found on svalue stack. -> from pike_frame 0x7faf32821a08 offset -140385920272696 **At position 12 among locals **Block: 0x7faf32821a08 Type: pike_frame Refs: 1 **Function _main at /Users/hww3/pikedbg/build/darwin-18.7.0-x86_64/master.pike:4069 ******************* ----------end------------ **Done looking for references to 0x10dd303f0, found 7 refs. Pike was in GC stage 100 when this fatal occurred. Backtrace at time of fatal: src/modules/_Debug/debug.cmod:652: lib/modules/Debug.pmod/Debugger.pmod/Breakpoint.pike() -:1: Stdio.FILE(2, "w", 777 /* fd=2 */)->write("\nSending response: \nContent-Length: 228\r\n\r\n{\"request_seq\":16,\"seq\":0,\"body\":{\"threads\":[{\"name\":\"Thread.Thread(4541273536)\",\"id\":4541273536},{\"nam"+[80]+"\"message\":null,\"success\":1,\"type\":\"response\"}\n") lib/modules/Stdio.pmod/module.pmod:1105: Stdio.FILE(2, "w", 777 /* fd=2 */)->write("\nSending response: \nContent-Length: 228\r\n\r\n{\"request_seq\":16,\"seq\":0,\"body\":{\"threads\":[{\"name\":\"Thread.Thread(4541273536)\",\"id\":4541273536},{\"nam"+[80]+"\"message\":null,\"success\":1,\"type\":\"response\"}\n") lib/modules/Stdio.pmod/module.pmod:2239: Stdio.FILE(2, "w", 777 /* fd=2 */)->write("\nSending response: \nContent-Length: 228\r\n\r\n{\"request_seq\":16,\"seq\":0,\"b"+[180]+"1,\"type\":\"response\"}\n","Content-Length: 228\r\n\r\n{\"request_seq\":16,\"seq\":0,\"body\":{\"threads\":[{\"n"+[159]+":1,\"type\":\"response\"}") build/darwin-18.7.0-x86_64/master.pike:6576: werror("\nSending response: \n%s\n","Content-Length: 228\r\n\r\n{\"request_seq\":16,\"seq\":0,\"body\":{\"threads\":[{\"name\":\"Thread.Thread(4541273536)\",\"id\":4541273536},{\"na"+[87]+"ge\":null,\"success\":1,\"type\":\"response\"}") lib/modules/Debug.pmod/Debugger.pmod/DebugServer.pike:31: Debug.Debugger.DebugServer()->write_response(Debug.Debugger.DebugAdapterProtocol.ThreadsResponse()) lib/modules/Debug.pmod/Debugger.pmod/DebugServer.pike:145: Debug.Debugger.DebugServer()->handle_threads_request(mapping[3]) lib/modules/Debug.pmod/Debugger.pmod/DebugServer.pike:678: Debug.Debugger.DebugServer()->breakpoint_read(Stdio.File("socket", "127.0.0.1 51892", 777 /* fd=10 */),"Content-Length: 47\r\n\r\n{\"command\":\"threads\",\"type\":\"request\",\"seq\":16}") lib/modules/Stdio.pmod/module.pmod:1165: Stdio.File("socket", "127.0.0.1 51892", 777 /* fd=10 */)->__stdio_read_callback() -:1: Pike.Backend(1)->`()(1000.0) lib/modules/Debug.pmod/Debugger.pmod/DebugServer.pike:540: Debug.Debugger.DebugServer()->__lambda_65700_0_line_540() Abort trap: 6

2 2

← Newer
1
...
6
7
8
9
10
11
12
...
304
Older →

Jump to page:

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