Pike-devel

pike-devel@lists.lysator.liu.se

1 participants
3041 discussions

Memory size accounting error
by Stephen R. van den Berg 01 Apr '21

01 Apr '21

Can anyone confirm that the following patch seems reasonable? Or am I seeing the results of anomalies I created/missed in the Buffer/Shuffler rewrites? Memory size accounting error. diff --git a/src/builtin_functions.c b/src/builtin_functions.c index 52534409d7..993ba05611 100644 --- a/src/builtin_functions.c +++ b/src/builtin_functions.c @@ -8262,6 +8262,7 @@ unsigned int rec_size_svalue( struct svalue *s, struct mapping **m ) case PIKE_T_FLOAT: case PIKE_T_FUNCTION: case PIKE_T_TYPE: + case PIKE_T_FREE: return 0; } if( !m ) return 0; Without this fix, obviously perhaps, it coredumps. Inserting a PIKE_T_FREE in a mapping does not work. -- Stephen.

2 3

SIGSEGV?
by Stephen R. van den Berg 01 Apr '21

01 Apr '21

Received signal SIGSEGV, Segmentation fault. new_get_return_type (fun_type=0x0, flags=flags@entry=0) at /home/srb/81pike/src/pike_types.cmod:11626 11626 while(fun_type->type == PIKE_T_ARRAY) { (gdb) where #0 new_get_return_type (fun_type=0x0, flags=flags@entry=0) at /home/srb/81pike/src/pike_types.cmod:11626 #1 0x00005555555f03be in new_get_return_type (fun_type=0x555556026e50, flags=flags@entry=0) at /home/srb/81pike/src/pike_types.cmod:11671 #2 0x00005555555f03be in new_get_return_type (fun_type=0x555556027ed0, flags=flags@entry=0) at /home/srb/81pike/src/pike_types.cmod:11671 #3 0x00005555555f03be in new_get_return_type (fun_type=0x555556027a90, flags=flags@entry=0) at /home/srb/81pike/src/pike_types.cmod:11671 #4 0x00005555555f03be in new_get_return_type (fun_type=0x555556027a50, flags=flags@entry=0) at /home/srb/81pike/src/pike_types.cmod:11671 #5 0x00005555555f03be in new_get_return_type (fun_type=fun_type@entry=0x555556027e50, flags=flags@entry=0) at /home/srb/81pike/src/pike_types.cmod:11671 #6 0x0000555555689faa in fix_type_field (n=n@entry=0x555555f11aa0) at /home/srb/81pike/src/las.cmod:4054 #7 0x000055555568f66f in optimize (n=0x555555f11aa0, n@entry=0x555555fca9e0) at /home/srb/81pike/src/las.cmod:4569 #8 0x0000555555695b38 in optimize_node (n=0x555555fca9e0) at /home/srb/81pike/src/las.cmod:4660 #9 optimize_node (n=0x555555fca9e0) at /home/srb/81pike/src/las.cmod:4654 #10 dooptcode (name=0x5555557d94f0, n=0x555555fca9e0, type=0x55555600a310, modifiers=1) at /home/srb/81pike/src/las.cmod:4989 #11 0x000055555557a09d in yyparse () at language.yacc:1065 #12 0x00005555556213c0 in do_yyparse () at /home/srb/81pike/src/pike_compiler.cmod:370 #13 0x0000555555625e99 in run_pass2 (c=0x5555559d4200) at /home/srb/81pike/src/pike_compiler.cmod:1241 #14 run_pass2 (c=0x5555559d4200) at /home/srb/81pike/src/pike_compiler.cmod:1216 #15 0x000055555562633e in f_compilation_compile (args=<optimized out>) at /home/srb/81pike/src/pike_compiler.cmod:1768 #16 0x0000555555587508 in lower_mega_apply (args=args@entry=0, o=o@entry=0x555555f002a8, fun=1) at /home/srb/81pike/src/interpret.c:2584 #17 0x0000555555587f0a in jump_opcode_F_CALL_OTHER (arg1=13) at /home/srb/81pike/src/interpret_functions.h:2424 #18 0x00007ffff7824dc0 in ?? () #19 0x0000000000000014 in ?? () #20 0x0000000000000050 in ?? () #21 0x00007ffff7a4d9f0 in ?? () #22 0x0000000000000000 in ?? () (gdb) list 11621 } 11622 #endif /* PIKE_DEBUG */ 11623 11624 loop: 11625 /* Count the number of array levels. */ 11626 while(fun_type->type == PIKE_T_ARRAY) { 11627 array_cnt++; 11628 fun_type = fun_type->cdr; 11629 } 11630 (gdb) p fun_type $1 = (struct pike_type *) 0x0 (gdb) -- Stephen.

1 2

Compression.Lz4
by Stephen R. van den Berg 01 Apr '21

01 Apr '21

For the new CQL driver I need Lz4 support. Now, instead of introducing yet another toplevel Lz4 object, how about moving Bz2 and Gz and Lz4 into: Compression.Bz2 Compression.Gz Compression.Lz4 Any objections? -- Stephen.

4 5

Destructed objects inside a multiset?
by Stephen R. van den Berg 29 Mar '21

29 Mar '21

Do they need to be weeded out manually? If so, how? Or do they magically vanish and if so, when does that actually happen? -- Stephen.

1 0

make_static_string()
by Stephen R. van den Berg 20 Mar '21

20 Mar '21

Is it allowed/supported to put a string created with make_static_string() into an svalue and then give it to say the write() method of an arbitrary Stdio object? -- Stephen.

4 15

Shuffler revisited (2)
by Stephen R. van den Berg 18 Mar '21

18 Mar '21

In an attempt to prepare the Shuffler for use on the database connection in the pgsql module, I delved back into the Shuffler code again. This time I achieved 99.9% comprehension of the code. The result is a considerable rewrite of the inner loop. The rewrite was necessary because: a. The shuffle-source-management still had memory leaks. b. The size of the buffer writes was arbitrarily large (depending on the input block size). c. The way wrap_callback results were stored resulted in (only) mostly-correct data. d. The data of sources were used ever so briefly *after* getting freed. -- Stephen.

1 0

cmod compilation: Bad integer ordering in lower_or_pike_types()?
by Stephen R. van den Berg 18 Mar '21

18 Mar '21

Any clue as to what I messed up here? #### Making dynamic: post_modules/SQLite #### Making dynamic: post_modules/Shuffler match_types mismatch! a: zero b: void res: NULL tmp: zero tmp2: zero match_types mismatch! a: zero b: void res: NULL tmp: zero tmp2: zero pike_types_le mismatch! a: function(mixed:void) b: scope(0, or(function(zero:mixed)|__deprecated__(function(zero:void)))) res: 1 tmp: scope(0, and(or(function(mixed:void)|function(not(zero):void))&__deprecated__(function(not(zero):void)))) tmp2: scope(0, and(or(function(mixed:void)|function(not(zero):void))&__deprecated__(function(not(zero):void)))) low_type_binop(0x0002, function(mixed:void), scope(0, or(function(zero:mixed)|__deprecated__(function(zero:void)))), 0x7fffb71ec3d0, 0x0000, 0x0000, 0x80) low_type_binop(0x0002, function(mixed:void), or(function(zero:mixed)|__deprecated__(function(zero:void))), 0x7fffb71ec3d0, 0x0000, 0x0000, 0x80) low_type_binop(0x0002, function(mixed:void), function(zero:mixed), 0x7fffb71ec3d0, 0x0000, 0x0000, 0x80) low_type_binop(0x0002, mixed, zero, 0x7fffb71ec3d0, 0x0200, 0x0200, 0x80) ret: not(zero) tmp: not(zero) low_type_binop(0x0002, function(:void), function(:mixed), 0x7fffb71ec3d0, 0x0000, 0x0000, 0x80) low_type_binop(0x0002, void, void, 0x7fffb71ec3d0, 0x0300, 0x0300, 0x80) ret: NULL tmp: NULL low_type_binop(0x0002, void, mixed, 0x7fffb71ec3d0, 0x0100, 0x0000, 0x80) ret: void ret: function(:void) ret: or(function(mixed:void)|function(not(zero):void)) low_type_binop(0x0002, function(mixed:void), __deprecated__(function(zero:void)), 0x7fffb71ec3d0, 0x0000, 0x0000, 0x80) low_type_binop(0x0002, function(mixed:void), function(zero:void), 0x7fffb71ec3d0, 0x0000, 0x0000, 0x80) low_type_binop(0x0002, mixed, zero, 0x7fffb71ec3d0, 0x0200, 0x0200, 0x80) ret: not(zero) tmp: not(zero) low_type_binop(0x0002, function(:void), function(:void), 0x7fffb71ec3d0, 0x0000, 0x0000, 0x80) ret: NULL ret: function(not(zero):void) ret: __deprecated__(function(not(zero):void)) ret: and(or(function(mixed:void)|function(not(zero):void))&__deprecated__(function(not(zero):void))) ret: scope(0, and(or(function(mixed:void)|function(not(zero):void))&__deprecated__(function(not(zero):void)))) tmp3: scope(0, and(or(function(mixed:void)|function(not(zero):void))&__deprecated__(function(not(zero):void)))) /home/srb/pike/src/pike_types.cmod:3254: Fatal error: Bad integer ordering in lower_or_pike_types(). No stack - no backtrace. make[5]: *** [Makefile:94: override] Aborted make[4]: *** [Makefile:106: Shuffler] Error 1 make[3]: *** [Makefile:1182: post-modules-stamp] Error 1 make[2]: *** [Makefile:231: all] Error 2 make[1]: *** [Makefile:149: _make_in_builddir] Error 2 make: *** [Makefile:66: compile] Error 2 Closer inspection at /home/srb/pike/src/pike_types.cmod:3254 reveals that: min1 = 0 min2 = ffffffff max1 = 7fffffff max2 = 0 -- Stephen.

1 1

debugger-wip merge
by H William Welliver 16 Mar '21

16 Mar '21

Hello all- I’m planning on merging the work in progress debugger into master in the coming days. A prior version of this code has been reviewed and it is my understanding from Mateusz that there were 1 or 2 unaddressed items. I’ve addressed one (handling of multiple offsets for a given line) and don’t think the other item (in what file a particular set of functions belongs) makes sense at the moment, based on my read of the code. I wouldn’t however, be opposed to someone who feels more strongly about relocating it. I’ve made a few other minor enhancements to the C-level code that I don’t think negatively impact the outcome of that review. The first thing to know is that the debugger actually works[1]. My plan is to split the code into 2 or 3 parts: the C-level bits, the debugger itself which lives in lib/modules/Debug/Debugger.pmod and the bootstrap code in master.pike. When it lands, I’ll also have some instructions for how to try it out. My base assumptions (hopefully obvious but I’ll state them nonetheless): 1. When not enabled at runtime, it is intended that the code is not in the path of execution. 2. When enabled, the code should not cause aborts. 3. "Surprise" behavior is possible, some of which is known[2] and some not. 4. Performance is assumed to be impacted while debugging. Attempts to minimize the negative impact are obviously of interest. 5. Everything here is private/uncommitted and subject to change should something better rear its head. Some caveats: 0. This is very much work in progress, but I commit to minimize impact to others and get things to a point where that’s no longer the case as quickly as possible. I felt it important to get this code out in front of more people to look at and try. Specifically: 1. I’ve made a good faith effort to not commit known bugs, but I’m sure there are some and will investigate any problems identified. 2. There is vestigial code that I’ve left in place to ease the inevitable troubleshooting and confidence building that are coming. The plan is to remove them when they are no longer needed. 3. There is behavior that might be pared back (specifically related to breakpoints across a range of offsets, which may not be needed). 4. The Pike level code is where most of the action currently is, and is most likely to see major change. 5. Semi-related: there /seems/ to be a problem in LiveBacktraceFrame in that argument names aren’t available, and it appears they’re not making it out of the compiler intact. I haven’t been able to track down the source of that problem. Assistance would be welcome. If anyone sees a major problem in any of this, please let me know. Bill [1] http://wiki.gotpike.org/PikeDevel%2FPikeDebugger [2] http://wiki.gotpike.org/index.pike?page=PikeDevel/PikeDebuggerCaveats (will be in place by tomorrow)

2 1

Re: Did someone already try to ask someone at Lysator?
by Chris Angelico 15 Mar '21

15 Mar '21

On Mon, Mar 15, 2021 at 10:22 PM Henrik Grubbström (Lysator) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > > Hi Stephen! > > > Did someone already try to ask someone at Lysator to push the power button? > > The power button wasn't the problem... > > The problem was due to the zpool version being bumped to a version not > supported by the version of GRUB on the bootdisks (Illumos bug 12780). > > That the hardware doesn't support booting the LiveUSB didn't help... > > We solved it by detaching the boot disk, putting it in a machine > that supported booting the LiveUSB, updating the boot block, and > then putting it back. > > Anyway, the machine has now been up for ~45 minutes. > > >I have, amongst other things, a fix for a fundamental data corruption bug > >in Stdio.Buffer which I fixed in master and in 8.0 waiting to be uploaded > >to the central git repository. > > The upstream repository should be fine now. > Thank you! Up and working. Very much appreciated. Now if I could just figure out how to implement generatorp()... ChrisA

1 0

Did someone already try to ask someone at Lysator?
by Stephen R. van den Berg 15 Mar '21

15 Mar '21

Did someone already try to ask someone at Lysator to push the power button? I have, amongst other things, a fix for a fundamental data corruption bug in Stdio.Buffer which I fixed in master and in 8.0 waiting to be uploaded to the central git repository. -- Stephen.

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
305
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