Pike-devel March 2018

pike-devel@lists.lysator.liu.se

6 participants
14 discussions

Filesystem.Monitor race condition
by H. William Welliver III 21 Mar '18

21 Mar '18

I’ve noticed that when using Filesystem.Monitor on a system with inotify there is the possibility of monitors being created on paths that don’t exist. Specifically, if a directory is created and deleted in very rapid succession, the inotify events are processed after the directory is already gone. The resulting Monitors hang around forever (with their associated polls). It doesn’t appear that any events get triggered for this situation, though I can’t be absolutely sure because I’m not watching for directory changes. My concern is that these phantom monitors can build up over time. Does it make sense to check for the existence of something before monitoring it? I didn’t want to assume that was desirable because I suppose it’s possible someone might want to watch with the expectation that it will exist later… (maybe?) Bill

3 5

Re: sqlite bug in Pike 8.1?
by H. William Welliver III 20 Mar '18

20 Mar '18

OK, I think I found the cause of the problem. The SQL module in 8.1 does things quite differently than in 8.0... There's a common Connection class that all of the database drivers inherit. Its code is called when you use sprintf() style bindings and under the covers converts a query() to a big_query(), which returns a Result object which it then converts back to the array of mappings that you expect query() to return. That's where the problem occurred. The Result object is designed for interacting with databases that return results in a streaming manner. There was an interaction with they way SQLite works (there's no "execute query" function per-se, so you step through the results and it executes the query as part of the stepping process). The code in Connection that converts a Result into an array looked to see if there were any fields in the result, and if none were present, it just stopped. That resulted in the query never being executed for those that may not return any colums (such as inserts, updates and deletes). I changed this method so that it fetches the rows before checking for the columns. A result without fields will likely not return any rows, so this shouldn't be a problem for databases that have already executed the query by this point. On a side note, I'm concerned that the conversion of query() to big_query() for bindings that already provide query() may be a performance regression... for example, the SQLite binding generates the result array in C, which should be at least somewhat faster than the Pike code used by Connection. I also suspect that there could be result differences since the code paths are so drastically different. Is there a reason for query() not to use the driver provided query() when it exists? Bill March 19, 2018 11:57 AM, "Matthew Clarke" <pclar7(a)yahoo.co.uk (mailto:%22Matthew%20Clarke%22%20<pclar7(a)yahoo.co.uk>)> wrote: Hi No I'm afraid that update didn't fix the problem though it doesn't crash the system now - just silently fails to insert anything into the table. int main() { Sql.Sql conn = Sql.Sql("sqlite://mydb.db"); conn->query("create table t(id int)"); array arr = ({ 14, 3, 7, 9, 100, 20, 5, 12 }); foreach (arr, int x) { conn->query("insert into t(id) values(%d)", x); //conn->query("insert into t(id) values(:a)", ([":a":x])); } array arr2 = conn->query("select * from t"); write("num rows=%dn", sizeof(arr2)); return 0; } The second of those query() calls (commented out) works but not the sprintf-style version. Regards, Matthew On Sunday, 18 March 2018, 04:02:13 GMT, H. William Welliver III <william(a)welliver.org (mailto:william@welliver.org)> wrote: Hey… sorry for the delay, the week got away from me. As I was looking into this, I noticed that grubba may have fixed the problem earlier today (not sure if he told you directly). If a current checkout doesn’t resolve the problem for you, let me know. Bill On Mar 11, 2018, at 1:37 PM, Matthew Clarke <pclar7(a)yahoo.co.uk (mailto:pclar7@yahoo.co.uk)> wrote: Hi Bill I posted again but I'm not sure that went through either. So if I email you directly... Here's the example: int main() { Sql.Sql conn = Sql.Sql("sqlite://mydb.db"); conn->query("create table t(id int)"); array arr = ({ 14, 3, 7, 9, 100, 20, 5, 12 }); foreach (arr, int x) { conn->query("insert into t(id) values(%d)", x); } return 0; } Works on 8.0.498 but not on 8.1.12. On 8.1.12 you need to use the other version of the query() method: conn->query("insert into t(id) values(:var)", ([":var":x])); Thanks & regards, Matthew On Sunday, 11 March 2018, 15:36:02 GMT, H. William Welliver III <william(a)welliver.org (mailto:william@welliver.org)> wrote: Hi… I’m not sure if you meant to include code examples, but they didn’t come through, and I don’t see your post on nabble. Can you resend it? Some changes were made to the sqlite binding to bring them in line with the way the other database bindings wok. It’s possible the change broke something but I’ll have to see what you’re doing to know for sure :) Bill > On Mar 11, 2018, at 7:26 AM, larcky <pclar7(a)yahoo.co.uk (mailto:pclar7@yahoo.co.uk)> wrote: > > Hi > This works perfectly in stable 8.0.498 but crashes in 8.1.12. > > > > To get it to work in 8.1.12, you have to use the other version of the > 'query' method: > > > Would it be possible to get the 'sprintf' variant working again? > Thanks, larcky > > > > > -- > Sent from: http://pike.1058338.n5.nabble.com/Pike-User-f4601254.html (http://pike.1058338.n5.nabble.com/Pike-User-f4601254.html) >

1 0

Bug in aclocal.m4?
by Pontus Östlund 16 Mar '18

16 Mar '18

I found the following in aclocal.m4 if test "x$enable_binary" = "no"; then Allthough I'm lamer in comparison to most developers, in my world that can never evaluate to true. It's been like that since 2002-01-27. I have no idea what the code folloing the statement does in practice though. And then I saw the following in configure.in # Do the below even when --disable-binary is used, since we need a # real $CPP, and AC_PROG_CPP wants AC_PROG_CC to be called earlier. # $CC will be overridden with a dummy later on. # MY_AC_PROG_CC # The above has problems if the smartlink binary is removed. /grubba Which seems somewhat related? Now, I have no idea what this code does so maybe there's nothing to bother about. But from a glance it looked somewhat suspicious so I though I'd report it. Regards ----------------------------- Pontus Östlund Developer • Roxen AB +46 70-662 81 69 www.roxen.com <http://www.roxen.com/> | twitter.com/roxen <https://twitter.com/roxen>

2 1

8.0 and precompiled pike files...
by Stephen R. van den Berg 07 Mar '18

07 Mar '18

The current git version of 8.0, but it has been this way for at least the past two months, works fine for me as long as I remove all *.o files from the installed version. If I do not do that, it crashes right away with a segmentation fault. It does not matter if I compile it with gcc 6, 7 or 8. Same result. Is that just on my system, or is this a generic .o file dumping problem in pike 8.0? I regularly compile with: --with-cdebug --without-rtldebug --without-valgrind --with-double-precision --with-long-int --disable-noopty-retry --with-machine-code --without-portable-bytecode -g -O2 on an amd64 linux system (devel2, to be exact, from pikefarm). -- Stephen.

1 2

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 March 2018