Pike-devel January 2006

pike-devel@lists.lysator.liu.se

8 participants
33 discussions

Stdio.File->write()
by Credence Shanden 10 Jan '06

10 Jan '06

I am getting a syntax error of Unexpected '(' from the following code: object o = Stdio.File("filepath", "wct+"); if(o) { o->write("foo"); o->close(); } the syntax error comes from the o->write("foo"); line. I have tried multiple variations of this and nothing works. Although in Hilfe it works. If I change it from write to Write it also compiles but then it does not write the data. I am currently running 7.6.50. --------------------------------- Yahoo! Photos Got holiday prints? See all the ways to get quality prints in your hands ASAP.

5 6

regression test bug?
by Bill Welliver 10 Jan '06

10 Jan '06

shouldn't this test pass (assuming I was doing a test_compile_warning_any)? If I run the code normally, I get a warning... Thoughts? Bill Doing tests in t (1 tests) t.in:14: Test 1 (shift 1) failed (expected compile warning). 1: 2: #pragma string_types 3: 4: class foo(string|int a) 5: { 6: void bar() 7: { 8: int b = a; 9: } 10: } 11: 12: object a = foo(1); 13: 14:

3 3

New beta: 7.6.64
by Peter Bortas ＠ Pike developers forum 09 Jan '06

09 Jan '06

http://pike.ida.liu.se/pub/pike/beta/7.6.64/Pike-v7.6.64.tar.gz

5 8

Leaks and dumps
by H. William Welliver III 09 Jan '06

09 Jan '06

> Hum... I don't rememeber of this code... Where it is ? (copying pike-devel, as I'm thinking there are potential pike issues at play here...) This code is from caudium.c; make_tag_attributes() and encode_mapping (). But I'm not convinced it's directly that code. Any arrays I created and passed to f_replace() cause the crash. If you create the arrays, push them onto the stack, skip calling f_replace() then pop them back off, the problem goes away, without memory leak. I also don't get the problem if I pass all strings to f_replace(), but that's a different set of replace code anyhow. There's a bunch of string builder code in f_replace, and string builder is also where things die later, so it makes me think there's something bad happening in there, though I realize that looks can be deceiving. For those in pike-devel land that might have a moment to comment, the code in question seems to be: static struct mapping *encode_mapping(struct mapping *mapping2encode, int encode_type) { struct array *indices, *values; struct mapping *result; struct pike_string *key = NULL, *val = NULL, *tmp = NULL; int i, j, k, do_replace; int size; indices = mapping_indices(mapping2encode); values = mapping_values(mapping2encode); size = (unsigned)indices->size; result = allocate_mapping(size); if(result == NULL) Pike_error("Can't allocate result mapping\n"); /* encode any key/value pair in the mapping */ for(i = 0; i < size; i++) { if(indices->real_item[i].type != T_STRING || values->real_item[i].type != T_STRING) continue; for(j = 0; j < 2; j++) { if(j == 0) tmp = indices->real_item[i].u.string; if(j == 1) tmp = values->real_item[i].u.string; /* let's see whether we have anything to encode */ do_replace = 0; if(encode_type == 1) for (k = 0; k < XML_UNSAFECHARS_SIZE; k++) { if (memchr(tmp->str, xml_unsafechars[k][0], tmp->len)) { do_replace = 1; break; } } if(encode_type == 0) for (k = 0; k < HTML_UNSAFECHARS_SIZE; k++) { if (memchr(tmp->str, html_unsafechars[k][0], tmp->len)) { do_replace = 1; break; } } if (do_replace) { push_string(tmp); if(encode_type == 1) { push_text("<"); push_text(">"); push_text("&"); push_text("\""); push_text("\'"); push_text("\000"); f_aggregate(6); push_text("<"); push_text(">"); push_text("&"); push_text("""); push_text("'"); push_text(""); f_aggregate(6); } if(encode_type == 0) { push_text("\""); f_aggregate(1); push_text("""); f_aggregate(1); } pop_n_elems(2); // f_replace(3); if(j == 0) copy_shared_string(key, Pike_sp[-1].u.string); if(j == 1) copy_shared_string(val, Pike_sp[-1].u.string); pop_stack(); } else { if(j == 0) copy_shared_string(key, tmp); if(j == 1) copy_shared_string(val, tmp); } } mapping_string_insert_string(result, key, val); } free_array(indices); free_array(values); return result; } the current code that's causing problems is: http://cvsweb.caudiumforge.net/cgi-bin/cvsweb.cgi/caudium/src/cmods/ _Caudium/caudium.c?rev=1.160;content-type=text%2Fx-cvsweb- markup;cvsroot=caudium Previously, the two arrays that would be passed to f_replace() were premade, and a copy was just passed in (though it's not clear that they needed to be copied). This all started when I went looking for a leak, and added the free_array() calls that you see in f_make_tag_attributes() and encode_mapping(). Apparently the code doesn't crash if you don't free those arrays (indices and values), and that's the original author wasn't freeing them, but I don't think it should be necessary to endure a memory leak just for the sake of the code not crashing. I can run this code for hours in an endless loop and not have problems or leaks, but caudium will die on the first request, usually somewhere inside Parser.HTML... I posed a backtrace to the main list a few days ago, but it had me totally confused. It might be worth mentioning that I had a problem with a similar end result (bus errors coming from malloc() by way of string builder code) with some code I was writing, but that didn't have anything to do with this caudium c module. Unfortunately, I can't produce that code because I didn't check it in anywhere, and resolved the problem by rewriting the pike code that seemed to trigger it. The similarity of the two results makes me think that perhaps there's a problem somewhere... Any suggestions? Bill

4 3

segfault
by Martin B�hr 09 Jan '06

09 Jan '06

the following code: $ cat foo.pike mixed __initstuff=lambda() { foobar=foobar->gazong; }(); void main() { return 0; } $ pike7.6 foo.pike foo.pike:3:Undefined identifier "foobar". foo.pike:3:Undefined identifier "foobar". foo.pike:3:Indexing a void expression. Segmentation fault fails without main() too. $ pike7.6 --dumpversion 7.6.33 i don't have a newer pike available at the moment. can anyone test this with the latest? greetings, martin.

5 5

Re: Leaks and dumps
by Mirar ＠ Pike developers forum 08 Jan '06

08 Jan '06

MAPPING_LOOP has been around for looping over mappings since very very early. When I wrote Image.JPEG I used it, and that was in 1997 or something...

1 0

Re: Leaks and dumps
by Martin Nilsson (Opera) ＠ Pike (-) developers forum 08 Jan '06

08 Jan '06

Well, to summarize: - You make indices and values and for-loops over them, instead of doing the c-version of foreach, NEW_MAPPING_LOOP. - You iterate over all characters in each string once to check for illegal characters and once more to replace them. The idea is that the check is more lightwieght than calling f_replace... - You push_text (instead of push_constant_text or pushing premade pike_string:s) and then aggregate them (instead of ref_pushing premade arrays) - You call f_replace with constant replace arrays instead of calling a premade replace object.

1 0

Re: segfault
by H. William Welliver III 08 Jan '06

08 Jan '06

pike t.pike t.pike:3:Undefined identifier "foobar". t.pike:3:Undefined identifier "foobar". t.pike:3:Indexing a void expression. Bus error bill-welliver:~/caudium/src/cmods/_Caudium hww3$ pike --dumpversion 7.6.50 I thought that this was fixed, but I guess I was mistaken. There was a whole class of these that caused crashes in .24, though. Bill On Jan 8, 2006, at 10:36 AM, Martin Bähr wrote: > mixed __initstuff=lambda() > { > foobar=foobar->gazong; > }(); > > void main() > { > return 0; > }

1 0

Valgrind
by Jonas Walld�n ＠ Pike developers forum 07 Jan '06

07 Jan '06

I just tried valgrinding 7.4-cvs (compiled with valgrind support) on x86_x64 and get the following warnings when starting hilfe: myst:7.4 $ ./bin/pike --valgrind=-q ==19948== Use of uninitialised value of size 8 ==19948== at 0x50168E: sub_node (las.c:439) ==19948== by 0x501881: debug_free_node (las.c:708) ==19948== by 0x50D152: dooptcode (las.c:5723) ==19948== by 0x422BC5: yyparse (language.yacc:864) ==19948== by 0x4D790E: run_pass2 (program.c:5864) ==19948== by 0x4D7C6D: compile (program.c:6081) ==19948== by 0x516F55: f_compile (builtin_functions.c:3331) ==19948== by 0x4ACBC0: get_master (object.c:552) ==19948== by 0x4ACE48: debug_master (object.c:598) ==19948== by 0x49E9DC: main (main.c:733) [repeated many times] --19948-- WARNING: unhandled syscall: 138 --19948-- You may be able to write your own handler. --19948-- Read the file README_MISSING_SYSCALL_OR_IOCTL. [repeated many times] Anyone that can determine if the first is a valid error or not? The second warning appears to be setfsuid() which is rather uninteresting from a memory validity standpoint.

2 2

p
by Erik Dahl, roxen ＠ Pike developers forum 05 Jan '06

05 Jan '06

3 2

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