Pike-devel

pike-devel@lists.lysator.liu.se

2 participants
3046 discussions

Fwd: [Pike-automation] New Defects reported by Coverity Scan for Pike-experiment
by Peter Bortas 17 Apr '16

17 Apr '16

Since Arne has been active on his faster_calls branch I switched the experiment stream on Coverity Scan to have a look at it. These are the new issues if found when going from marty/optimised_map to arne/faster_calls. Without looking closer I suspect the four in Image isn't related to the optimizations code, but the two in interpreter probably are. If you want to have a look at them follow the link at the bottom. Gives a better overview than the condensed ASCII in this mail. -- Peter Bortas ---------- Forwarded message ---------- From: <scan-admin(a)coverity.com> Date: Sun, Apr 17, 2016 at 6:48 PM Subject: [Pike-automation] New Defects reported by Coverity Scan for Pike-experiment To: pike-automation(a)lists.lysator.liu.se Hi, Please find the latest report on new defect(s) introduced to Pike-experiment found with Coverity Scan. 6 new defect(s) introduced to Pike-experiment found with Coverity Scan. 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 6 of 6 defect(s) ** CID 1358595: Incorrect expression (UNUSED_VALUE) /home/covscan/pike/pike-git/src/interpret.c: 2202 in unlink_previous_frame() ________________________________________________________________________________________________________ *** CID 1358595: Incorrect expression (UNUSED_VALUE) /home/covscan/pike/pike-git/src/interpret.c: 2202 in unlink_previous_frame() 2196 */ 2197 current->save_sp=prev->save_sp; 2198 current->save_mark_sp=prev->save_mark_sp; 2199 current->flags = prev->flags; 2200 2201 /* Unlink the top frame temporarily. */ >>> CID 1358595: Incorrect expression (UNUSED_VALUE) >>> Assigning value from "prev" to "Pike_interpreter_pointer->frame_pointer" here, but that stored value is overwritten before it can be used. 2202 Pike_interpreter.frame_pointer=prev; 2203 2204 #ifdef PROFILING 2205 { 2206 /* We must update the profiling info of the previous frame 2207 * to account for that the current frame has gone away. ** CID 1358594: Control flow issues (MISSING_BREAK) /home/covscan/pike/pike-git/src/interpret.c: 1956 in do_trace_frame_call() ________________________________________________________________________________________________________ *** CID 1358594: Control flow issues (MISSING_BREAK) /home/covscan/pike/pike-git/src/interpret.c: 1956 in do_trace_frame_call() 1950 safe_describe_svalue(&obj_sval, 0, NULL); 1951 obj_name = complex_free_buf(&save_buf); 1952 PIKE_FN_START(function->name->size_shift == 0 ? 1953 function->name->str : "[widestring fn name]", 1954 obj_name.str); 1955 } >>> CID 1358594: Control flow issues (MISSING_BREAK) >>> The above case falls through to this one. 1956 case FRAME_CLONE: 1957 case FRAME_PARENT_CLONE: 1958 if (UNLIKELY(Pike_interpreter.trace_level)) { 1959 struct svalue tmp; 1960 struct program *p = frame->ptr; 1961 dynamic_buffer save_buf; ** CID 1358593: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match_phase() ________________________________________________________________________________________________________ *** CID 1358593: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match_phase() 196 DOUBLE_LOOP(0,1,1, *1, *1, *1) 197 else if (type==2) 198 DOUBLE_LOOP(0, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 199 else if (type==3) 200 DOUBLE_LOOP(AVOID_IS_TOO_BIG,1,1, *1, *1, *1) 201 else if (type==4) >>> CID 1358593: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "haystack_certi". 202 DOUBLE_LOOP(AVOID_IS_TOO_BIG, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 203 204 #undef NORMCODE 205 #undef AVOID_IS_TOO_BIG 206 #undef PIXEL_VALUE_DISTANCE 207 #undef DOUBLE_LOOP ** CID 1358592: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match_norm_corr() ________________________________________________________________________________________________________ *** CID 1358592: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match_norm_corr() 196 DOUBLE_LOOP(0,1,1, *1, *1, *1) 197 else if (type==2) 198 DOUBLE_LOOP(0, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 199 else if (type==3) 200 DOUBLE_LOOP(AVOID_IS_TOO_BIG,1,1, *1, *1, *1) 201 else if (type==4) >>> CID 1358592: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "haystack_certi". 202 DOUBLE_LOOP(AVOID_IS_TOO_BIG, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 203 204 #undef NORMCODE 205 #undef AVOID_IS_TOO_BIG 206 #undef PIXEL_VALUE_DISTANCE 207 #undef DOUBLE_LOOP ** CID 1358591: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match_norm() ________________________________________________________________________________________________________ *** CID 1358591: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match_norm() 196 DOUBLE_LOOP(0,1,1, *1, *1, *1) 197 else if (type==2) 198 DOUBLE_LOOP(0, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 199 else if (type==3) 200 DOUBLE_LOOP(AVOID_IS_TOO_BIG,1,1, *1, *1, *1) 201 else if (type==4) >>> CID 1358591: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "haystack_certi". 202 DOUBLE_LOOP(AVOID_IS_TOO_BIG, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 203 204 #undef NORMCODE 205 #undef AVOID_IS_TOO_BIG 206 #undef PIXEL_VALUE_DISTANCE 207 #undef DOUBLE_LOOP ** CID 1358590: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match() ________________________________________________________________________________________________________ *** CID 1358590: Null pointer dereferences (FORWARD_NULL) /home/covscan/pike/pike-git/src/modules/Image/match.h: 202 in image_match() 196 DOUBLE_LOOP(0,1,1, *1, *1, *1) 197 else if (type==2) 198 DOUBLE_LOOP(0, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 199 else if (type==3) 200 DOUBLE_LOOP(AVOID_IS_TOO_BIG,1,1, *1, *1, *1) 201 else if (type==4) >>> CID 1358590: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "haystack_certi". 202 DOUBLE_LOOP(AVOID_IS_TOO_BIG, haystack_certi[j], needle_certi[ny*nxs+nx],.r,.g,.b) 203 204 #undef NORMCODE 205 #undef AVOID_IS_TOO_BIG 206 #undef PIXEL_VALUE_DISTANCE 207 #undef DOUBLE_LOOP ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/pike-experiment?tab=overview

1 0

pike -x benchmark
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 15 Apr '16

15 Apr '16

I noticed that starting the benchmark allocates an enormous amount of memory. The reason seems to be Foreach{,2,3,4} benchmarks. Each of these has the line array const_array = enumerate(10000000); on the top level. This means that there is an object occupying 160M (10M * sizeof(svalue)) in each of these _programs_, so it is always present when the programs are loaded, not just when the benchmarks are run. So in short, loading these four benchmarks (pike -x benchmark loads all the benchmarks) allocates 640M ram. That's a bit steep for my Raspberry Pi which only has 1G in total... (If I change the size of the arrays to 3M elements then the benchmarks complete normally.) Could perhaps each of these arrays be allocated before the respective benchmark is run, and freed afterwards, instead of being allocated when the benchmark is loaded and freed never?

1 0

Re: Pike 8.0.222 release candidate
by Chris Angelico 05 Apr '16

05 Apr '16

On Wed, Apr 6, 2016 at 9:50 AM, Peter Bortas @ Pike developers forum <10353(a)lyskom.lysator.liu.se> wrote: >>I can't recommend this to my users while it ships GTK 2.12.11 :( Is >>there anything I can do to help out there? > > Well. GTK+ used to be available as an all-in-one package for Windows > with a readme file saying > > "This is a bundle containing the GTK+ stack and its dependencies for > Windows. As such it is nothing more than a combination of the > individual packages it consists of. For a list, see > share/doc/gtk+-bundle-2.12.11-20080707/components.lst. Both run-time > and developer packages are included." > > I _think_ that is discontinued. If you can figure out a place to get a > working build environment for compiling with Visual Studio that would > help a bit. If you can find a place to get something that works with > VC9 it would help even more. According to this page [1], the current versions require Vista or later. Not sure whether that means GTK3 or GTK2 though. What Windows versions is Pike aiming to support? ChrisA [1] http://www.gtk.org/download/windows.php

2 1

Pike 8.0.222 release candidate
by Peter Bortas 05 Apr '16

05 Apr '16

No final release today. The disk in my virtual Windows machine broke. Fixing that took up time that should have been used for testing, so you will only get some completely untested builds. Pike 8.0.222 release candidate: https://pike.lysator.liu.se/pub/pike/beta/8.0.222/Pike-v8.0.222.tar.gz Windows build: https://pike.lysator.liu.se/pub/pike/beta/8.0.222/Pike-v8.0.222-win32-oldli… Changes since Pike 8.0.182 (release 2) ---------------------------------------------------------------------- New features ------------ o Roxen.http_decode_string() now decodes UTF-16 surrogate pairs. o Protocols.HTTP.Query now always sends a content-length header. o Report feature flags for System.FSEvents and System.Inotify. Bug fixes --------- o The machine code generator on ia32 now aligns the stack on a 16 byte boundary. This makes it possible to call code that uses SSE2 instructions. o Exceptions thrown in GTK signal handlers no longer cause segfaults. o The SSL client code now interprets the RFCs more leniently. o Multiple fixes for the handling of accelerated Filesystem.Monitor monitors, which could sometimes lose notifications. o Improved handling of response content-length in Protocols.HTTP.Query. o Fixed case where unfinished programs could lose their parents. o Fixed "Invalid service"-error from connect() on Fedora Core 4. o Fixed next_result() in Sql.sql_array_result. o Fixed sizeof() in Array.Iterator, Multiset.Iterator and String.Iterator. Building and installing ----------------------- o Multiple fixes for building on Solaris. o Improved scanning for Odbc header files. o Fixed some issues with --with-abi flags not propagating correctly to the modules. -- Peter Bortas

3 2

New stable next week
by Peter Bortas 30 Mar '16

30 Mar '16

Heads up: The next 8.0 release will be next Tuesday, March 5. Regards, -- Peter Bortas

2 1

bug in SSL.File()->set_alert_callback()?
by Bill Welliver 29 Mar '16

29 Mar '16

I've noticed that in 8.0, calls to SSL.File()->set_alert_callback() attempt to call set_alert_callback() on the underlying Connection object. That seems problematic to me, as the connection object is no longer being created in the constructor, so there doesn't appear to be any other way to set an alert callback before the possibility of an alert being generated. Does anyone know if this was an oversight, or by design? Currently set_alert_callback() generates an indexing error which seems wrong regardless. Thanks! Bill

1 0

Calendar.Timezone etc. - Up-to-date timezone and daylight savings data
by Magnus Holmgren, Millnet/Lysator/Debian/Mensa ＠ Pike developers forum 26 Mar '16

26 Mar '16

I'm thinking about getting around to integrating Pike with the tzdata package in Debian, which I was talking about at the conference some years ago, but I need to check and understand some things first. If I understand correctly, the Calendar module knows about daylight savings time and other jumps in local time in different regions, which is has to in order to convert past moments in time between local and universal time, but it doesn't make use of the operating system for this (except to find out what the current local timezone is), only data provided with the source code (which as of 8.0.182 is from 2013). Now, there is mkrules.pike, which compiles the tzdata files into a set of classes, but it apparently isn't run at build time and while I guess that one could use the generated classes directly, I can't see that they are used by Calendar.Timezone. The following comment suggests that mkrules.pike was discontinued but left in the source tree. // ================================================================ // this is to runtime-compile timezones // it's not very nice; based on the one-time-compilation // utility I wrote first - but that method was too slow :/ // ================================================================ Now, having the tzdata source package create a tzdata-pike package by running mkrules.pike would have created a bootstrapping problem as pike8.0-core would depend on a package that itself would be needed for to build, so perhaps it's only easier to create a package that simply installs the tzdata source files in the right location?

2 2

Re: Segfault in colortable.c
by Chris Angelico 25 Mar '16

25 Mar '16

On Fri, Mar 25, 2016 at 10:55 PM, Martin Nilsson (Coppermist) @ Pike (-) developers forum <10353(a)lyskom.lysator.liu.se> wrote: > Probably correct. We really should have all the image operations > performed in the image testasuite as well... Okay, pushed to 8.1 then. Thanks. ChrisA

1 0

Segfault in colortable.c
by Chris Angelico 25 Mar '16

25 Mar '16

I've been digging into a segfault that was preventing 'make doc' from operating correctly, and pinned it down to this code: src/modules/Image/colortable.c:2010 - rnd->u.refs++; + ++*rnd->u.refs; and corresponding decrementing of the refcount. The count appears to be a pointer, not a direct integer, so it looks like it ought to be dereferenced here. Not 100% sure the fix is correct though, so I pushed to branch rosuav/colortable-segfault instead of directly to 8.1. Can someone check it, please? Test case, cribbed from the code behind 'make doc': #define IMAGE_DIR "/home/rosuav/pike/refdoc/src_images/" object lena() { catch { return Image.load(IMAGE_DIR + "image_ill.pnm"); }; catch { return Image.load(IMAGE_DIR + "lena.ppm"); }; catch { return Image.load(IMAGE_DIR + "lenna.rs"); }; return Image.load(IMAGE_DIR + "lena.gif"); } int main() { object c=Image.Colortable(lena(),2)->randomcube(60,60,60); c*lena(); } ChrisA

2 1

Windows-Hilfe
by Martin Nilsson (Coppermist) ＠ Pike (-) developers forum 23 Mar '16

23 Mar '16

Anyone know what termcaps should be on windows cmd terminal? It's super-annoying not having history in hilfe.

1 0

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