pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2013-08-28T15:12:22Zhttps://git.lysator.liu.se/pikelang/pike/-/issues/4631Parsing problems in XMLRPC module (and in the xml parser)2013-08-28T15:12:22ZPeter BortasParsing problems in XMLRPC module (and in the xml parser)Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4631
Reported by Manifest0 , <demanuel@gmail.com>
The xmlrpc can't process the opensubtitles xml response.
```
Steps to reproduce:
Protocols.XMLRPC.Client cliente = Prot...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4631
Reported by Manifest0 , <demanuel@gmail.com>
The xmlrpc can't process the opensubtitles xml response.
```
Steps to reproduce:
Protocols.XMLRPC.Client cliente = Protocols.XMLRPC.Client("http://
www.opensubtitles.org/xml-rpc");
string auth_token = cliente["LogIn"]("","","en","python")[0]["token"];
array(mapping(string:string)) map =({});
mapping(string:string) params = ([]);
params["sublanguageid"]="eng";
params["moviehash"]="8c7419a68bd85bd8";
params["moviebytesize"]="733700096";
map+=({params});
cliente["SearchSubtitles"](auth_token,map);
```
Error:
Bad arguments.
Unknown program: `*(0,"")
Other info:
1- It seems that the bug is both in the xml parser and in the xmlrpc module
2- You can see the xml response by using the following code:
```
Protocols.XMLRPC.Client cliente = Protocols.XMLRPC.Client("http://
www.opensubtitles.org/xml-rpc");
string auth_token = cliente["LogIn"]("","","en","python")[0]["token"];
array(mapping(string:string)) map =({});
mapping(string:string) params = ([]);
params["sublanguageid"]="eng";
params["moviehash"]="8c7419a68bd85bd8";
params["moviebytesize"]="733700096";
map+=({params});
object c=Protocols.HTTP.do_method("POST", cliente->url, 0,
(["Content-Type":"text/xml"]), 0,
Protocols.XMLRPC.encode_call("SearchSubtitles", ({ auth_token, map })));
string result=c->data();
write(result);
```
I hope o didn't forget anything.
Best regards!Pike 7.6Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/4537Array gets emptied if modified in function2009-04-16T14:11:39ZPeter BortasArray gets emptied if modified in functionImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4537
Reported by @zino
Pike 7.7.45 from CVS as of a few hours ago:
```
% cat bug_array.pike
void fiddle(array a)
{
a += ({ 2 });
}
void main()
{
array a = ({});...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4537
Reported by @zino
Pike 7.7.45 from CVS as of a few hours ago:
```
% cat bug_array.pike
void fiddle(array a)
{
a += ({ 2 });
}
void main()
{
array a = ({});
fiddle( a );
if(!sizeof(a))
werror("Array is broken: %O\n", a);
else
werror("Array is ok: %O\n", a);
}
% ~/bin/pike77-2/bin/pike bug_array.pike
Array is broken: ({ })
```
(Initially reported by Tim Johansson, Opera Software)Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/4174(file << "foo") << "bar" don't compile on pike 7.6 (work fine with 7.2) (See ...2009-04-16T14:11:39ZPeter Bortas(file << "foo") << "bar" don't compile on pike 7.6 (work fine with 7.2) (See also #2996, #4156)Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4174
Reported by Andrew Shirrayev, <andrews@gate.ort.spb.ru>
```
~$ pike7.2
Pike v7.2 release 580 running Hilfe v2.0 (Incremental Pike Frontend)
> (Stdio.stdout << "BAR!\...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4174
Reported by Andrew Shirrayev, <andrews@gate.ort.spb.ru>
```
~$ pike7.2
Pike v7.2 release 580 running Hilfe v2.0 (Incremental Pike Frontend)
> (Stdio.stdout << "BAR!\n") << "FOO!\n";
BAR!
FOO!
Result: object
Terminal closed.
~$ pike7.6
Pike v7.6 release 75 running Hilfe v3.5 (Incremental Pike Frontend)
> (Stdio.stdout << "BAR!\n") << "FOO!\n";
Compiler Error: 1:Bad argument 2 to `<<.
Compiler Error: 1:Expected: !function(!object ... : mixed) &
(function(mixed, object : mixed) | function(object, mixed : mixed)) |
function(int, int : int)
Compiler Error: 1:Got : function(mixed, string : void | mixed)
Terminal closed.
```Pike 7.6Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/4052ORA-03106: fatal two-task communication protocol error with Oracle 9i+2015-11-05T17:43:41ZPeter BortasORA-03106: fatal two-task communication protocol error with Oracle 9i+Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4052
Reported by Peter J. Holzer, WSR <hjp@wsr.ac.at>
```
Pike v7.4 release 340 Copyright &#65533; 1994-2004 Linköping University
(part of the Roxen 4.0.425 distribution)...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4052
Reported by Peter J. Holzer, WSR <hjp@wsr.ac.at>
```
Pike v7.4 release 340 Copyright � 1994-2004 Linköping University
(part of the Roxen 4.0.425 distribution):
```
When pike is built against Oracle 9.2.0.1 or Oracle 10.2, some (but not all)
queries on an Oracle 9.2.0.6 database result in an ORA-03106 error after
the first row of the result set is returned. The problem always occurs for
the same queries, but I haven't found a pattern, which queries are affected.
When pike is built against Oracle 8.1.7 OR the database is Oracle 8.1.7,
the problem doesn't occur - both the database and the libraries need to be
9i or later to show the problem.
To reproduce:
```
In sqlplus:
set autocommit on
create table foo (KST0 int, kst1 int, name varchar2(80), aktuell number(1));
insert into foo values(1,2, 'Test', 1);
insert into foo values(3, 4, 'fasel', 0);
```
In Roxen Admin interface:
SELECT KST0, KST1, NAME, AKTUELL FROM FOO => Run Query
Works.
```
again in sqlplus:
delete from foo where kst0=3;
insert into foo values(0, 2, 'Administratives', 1);
```
Click again on Run Query in Roxen:
KST0 KST1 NAME AKTUELL
0 2 Administratives 1
While running SELECT KST0, KST1, NAME, AKTUELL FROM FOO :
OCIStmtFetch:code=-1:ORA-03106: fatal two-task communication protocol error
Query took 0.001s, 1 rows in the replyPike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3947SDL.set_video_mode() breaks Pike on Mac OS X.3.9 and SDL 1.2.82020-03-01T14:50:31ZPeter BortasSDL.set_video_mode() breaks Pike on Mac OS X.3.9 and SDL 1.2.8Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3947
Reported by Hermann Kruud, <hermannkruud@yahoo.co.uk>
```
This call:
SDL.set_video_mode(320, 240, 16, SDL.SWSURFACE);
```
breaks on Pike v7.7 release 21 (also v...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3947
Reported by Hermann Kruud, <hermannkruud@yahoo.co.uk>
```
This call:
SDL.set_video_mode(320, 240, 16, SDL.SWSURFACE);
```
breaks on Pike v7.7 release 21 (also v7.6 release 24 and v7.4 release 25)
and gives:
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
...
2005-07-03 22:27:39.224 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48e640 of class NSCFArray autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.225 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x438720 of class NSCFArray autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.226 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48edb0 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.227 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4376b0 of class NSCFArray autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.227 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4201c0 of class NSCFArray autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.228 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48ee10 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.229 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48ee30 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.229 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48ee50 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.230 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48ee70 of class NSCFArray autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.231 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4560e0 of class NSCFArray autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.231 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48ee90 of class NSPathStore2 autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.232 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48eef0 of class NSPathStore2 autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.232 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48ef20 of class NSPathStore2 autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.233 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48eff0 of class NSPathStore2 autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.234 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48f030 of class NSCFDictionary autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.235 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48f0f0 of class NSIdEnumerator autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.236 pike[9057] *** _NSAutoreleaseNoPool(): Object
0xa2e7e924 of class NSCFString autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.237 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48f150 of class NSCFArray autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.238 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4642b0 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.239 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x464900 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.240 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x464d70 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.241 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x464910 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.242 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4648d0 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.242 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x464d30 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.243 pike[9057] *** _NSAutoreleaseNoPool(): Object
0xa2e7e8b4 of class NSCFString autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.244 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x461bb0 of class NSCFNumber autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.247 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48fdf0 of class NSCFData autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.253 pike[9057] *** _NSAutoreleaseNoPool(): Object
0xa2e7b0d0 of class NSCFString autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.256 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x490840 of class _NSCachedBitmapImageRep autoreleased with no pool in
place - just leaking
2005-07-03 22:27:39.259 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48fcf0 of class NSImage autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.260 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x491130 of class _NSCachedBitmapImageRep autoreleased with no pool in
place - just leaking
2005-07-03 22:27:39.261 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x491010 of class NSImage autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.262 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48eb40 of class _NSThemeCloseWidget autoreleased with no pool in place -
just leaking
2005-07-03 22:27:39.264 pike[9057] *** _NSAutoreleaseNoPool(): Object
0xa2e7b0d0 of class NSCFString autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.265 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x491750 of class _NSCachedBitmapImageRep autoreleased with no pool in
place - just leaking
2005-07-03 22:27:39.266 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4915a0 of class NSImage autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.268 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4915f0 of class _NSCachedBitmapImageRep autoreleased with no pool in
place - just leaking
2005-07-03 22:27:39.268 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x4917e0 of class NSImage autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.269 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x491320 of class _NSThemeWidget autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.270 pike[9057] *** _NSAutoreleaseNoPool(): Object
0xa2e7b0d0 of class NSCFString autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.271 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x490730 of class _NSCachedBitmapImageRep autoreleased with no pool in
place - just leaking
2005-07-03 22:27:39.272 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48ebc0 of class NSImage autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.273 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x47ed60 of class _NSCachedBitmapImageRep autoreleased with no pool in
place - just leaking
2005-07-03 22:27:39.274 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x47c0b0 of class NSImage autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.275 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x491ac0 of class _NSThemeWidget autoreleased with no pool in place - just
leaking
2005-07-03 22:27:39.277 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x491440 of class NSCFString autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.278 pike[9057] *** _NSAutoreleaseNoPool(): Object
0x48c900 of class NSException autoreleased with no pool in place - just leaking
2005-07-03 22:27:39.279 pike[9057] *** Uncaught exception:
<NSInternalInconsistencyException> Error (1002) creating CGSWindow
```
Backtracing on GDB gives:
#0 0x90a8d318 in _NSRaiseError ()
#1 0x90a8d1fc in +[NSException raise:format:] ()
#2 0x92f54518 in _NSCreateWindowWithOpaqueShape ()
#3 0x92f032bc in -[NSWindow _commonAwake] ()
#4 0x92ed0b30 in -[NSWindow _commonInitFrame:styleMask:backing:defer:] ()
#5 0x92ec04d8 in -[NSWindow
_initContent:styleMask:backing:defer:contentView:] ()
#6 0x92f408b8 in -[NSWindow
initWithContentRect:styleMask:backing:defer:] ()
#7 0x014c4e1c in -[SDL_QuartzWindow
initWithContentRect:styleMask:backing:defer:] (self=0x0, _cmd=0x0,
contentRect={origin = {x = 0, y = 0}, size = {width = 320, height = 240}},
styleMask=8388608, backingType=2733245164, flag=0 '\0') at
SDL_QuartzWindow.m:196
#8 0x014c35cc in QZ_SetVideoWindowed (this=0x47b5f0, current=0x0,
width=536870912, height=-1073750704, bpp=8388608, flags=0) at
SDL_QuartzVideo.m:737
#9 0x014c3a58 in QZ_SetVideoMode (this=0x858600, current=0x14f535c,
width=536870912, height=-1073750704, bpp=32, flags=1) at SDL_QuartzVideo.m:845
#10 0x014cca34 in SDL_SetVideoMode (width=0, height=240, bpp=16,
flags=0) at SDL_video.c:661
#11 0x01258190 in f_set_video_mode ()
#12 0x0002e2c8 in low_mega_apply ()
#13 0x000265b8 in jump_opcode_F_APPLY_AND_RETURN ()
#14 0x0121ae08 in ?? ()
#15 0x0002fe5c in o_catch ()
#16 0x0001e428 in jump_opcode_F_CATCH ()
#17 0x01211368 in ?? ()
#18 0x0002fcd0 in mega_apply ()
#19 0x000e2ec0 in call_pike_initializers ()
#20 0x000e340c in parent_clone_object ()
#21 0x0002e320 in low_mega_apply ()
#22 0x000278fc in jump_opcode_F_CALL_OTHER_AND_POP ()
#23 0x006803c0 in ?? ()
#24 0x0002fcd0 in mega_apply ()
#25 0x000034ec in main ()
#26 0x0000237c in _start (argc=3, argv=0xbffff710, envp=0xbffff720) at
/SourceCache/Csu/Csu-47/crt.c:267
#27 0x8fe1a278 in __dyld__dyld_start ()
```Pike 7.6Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3916Pike 7.6 and 7.7 doesn't compile on FreeBSD 5.4-RELEASE2009-04-16T14:11:39ZPeter BortasPike 7.6 and 7.7 doesn't compile on FreeBSD 5.4-RELEASEImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3916
Reported by Xavier Beaudouin, Xavier Beaudouin <kiwi@oav.net>
On FreeBSD 5.4-RELEASE (as well on 5.3) compiler fails with :
```
Making GL
gmake[5]: Entering directo...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3916
Reported by Xavier Beaudouin, Xavier Beaudouin <kiwi@oav.net>
On FreeBSD 5.4-RELEASE (as well on 5.3) compiler fails with :
```
Making GL
gmake[5]: Entering directory `/home/kiwi/xenoclient/pike-7.6/glopy.fr.tiscali.com/buildtmp/
Pike-v7.6-snapshot/build/freebsd-5.4-release-i386/post_modules/GL'
gmake[6]: Entering directory `/home/kiwi/xenoclient/pike-7.6/glopy.fr.tiscali.com/buildtmp/
Pike-v7.6-snapshot/build/freebsd-5.4-release-i386/post_modules/GL'
Compiling /home/kiwi/xenoclient/pike-7.6/glopy.fr.tiscali.com/buildtmp/Pike-v7.6-snapshot/
src/post_modules/GL/top.c
/home/kiwi/xenoclient/pike-7.6/glopy.fr.tiscali.com/buildtmp/Pike-v7.6-snapshot/build/
freebsd-5.4-release-i386/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/
kiwi/xenoclient/pike-7.6/glopy.fr.tiscali.com/buildtmp/Pike-v7.6-snapshot/build/freebsd-5.4-
release-i386/master.pike /home/kiwi/xenoclient/pike-7.6/glopy.fr.tiscali.com/buildtmp/Pike-
v7.6-snapshot/src/post_modules/GL/gen.pike < /home/kiwi/xenoclient/pike-7.6/
glopy.fr.tiscali.com/buildtmp/Pike-v7.6-snapshot/src/post_modules/GL/auto.c.in > auto.c
Fatal error 'Spinlock called when not threaded.' at line 87 in file /usr/src/lib/libpthread/thread/
thr_spinlock.c (errno = 2)
Abort trap (core dumped)
gmake[6]: *** [auto.c] Error 134
```
This bug is also present on pike 7.7 as well.
Please see xenofarm for glopy.fr.tiscali.com (warning this machine will be dead Friday 13th
because I quit Tiscali as job).
http://pike.ida.liu.se/generated/pikefarm/7.6/271_201/makelog.html
http://pike.ida.liu.se/generated/pikefarm/7.7/900_161/makelog.htmlPike 7.6Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3812Sort is broken2009-04-16T14:11:39ZPeter BortasSort is brokenImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3812
Reported by Fredrik Noring, Roxen Internet Software <noring@roxen.com>
The following works in Pike 7.2 but fails in Pike 7.4:
```
int main()
{
array a = ({ /* 94 ...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3812
Reported by Fredrik Noring, Roxen Internet Software <noring@roxen.com>
The following works in Pike 7.2 but fails in Pike 7.4:
```
int main()
{
array a = ({ /* 94 elements */
90839040,
96352256,
80316416,
88322048,
73676800,
77709312,
101908480,
72744960,
54609920,
251849736,
62978048,
106463232,
820152320,
111521792,
43429888,
72683520,
99155968,
106059776,
69969920,
131769352,
34936832,
54810624,
90839040,
94869504,
94869504,
106463232,
56076288,
106059776,
99418112,
115529728,
100892672,
64229376,
100124672,
110780416,
101908480,
290721792,
58802176,
111521792,
68894720,
58322944,
93726720,
95713280,
79521792,
157540352,
69969920,
115529728,
108609536,
72300544,
72744960,
88031232,
95713280,
120080384,
110376960,
63164416,
86994944,
103079936,
68622336,
54810624,
60518400,
103079936,
107485184,
58411008,
366772224,
72769536,
58322944,
291342336,
97054720,
64915456,
68485120,
72769536,
99155968,
4792706056,
121389056,
60237824,
56006656,
60237824,
60518400,
68485120,
108003328,
88322048,
58802176,
108072960,
195770368,
93726720,
88031232,
73601024,
110780416,
54609920,
53366784,
142299136,
70117376,
64229376,
85239808,
53366784
});
a = map((array(string))a, Gmp.mpz, 10);
array b = (array(string))a;
sort(a, b);
write("%O\n", a);
return 0;
}
```Pike 7.4https://git.lysator.liu.se/pikelang/pike/-/issues/3618BACKPORT: Type error segfault.2009-04-16T14:11:39ZPeter BortasBACKPORT: Type error segfault.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3618
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
```
The code
Stdio.File o = Stdio.FakeFile("");
```
generates
```
Program received signal SIGSEGV, Segmen...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3618
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
```
The code
Stdio.File o = Stdio.FakeFile("");
```
generates
```
Program received signal SIGSEGV, Segmentation fault.
0x42070664 in _IO_default_xsputn () from /lib/i686/libc.so.6
(gdb) bt
#0 0x42070664 in _IO_default_xsputn () from /lib/i686/libc.so.6
#1 0x42047e92 in vfprintf () from /lib/i686/libc.so.6
#2 0x4206aa54 in vsnprintf () from /lib/i686/libc.so.6
#3 0x080f61f0 in va_yyerror (fmt=0x42135980 "", args=0x42135980 "")
at /home/nilsson/Pike/7.5/src/program.c:5850
#4 0x080f6218 in my_yyerror (fmt=0x42135980 "")
at /home/nilsson/Pike/7.5/src/program.c:5858
#5 0x080d4d53 in yyexplain_nonmatching_types (type_a=0x4213920c,
type_b=Cannot access memory at address 0xbf7ffffc
)
at /home/nilsson/Pike/7.5/src/pike_types.c:4479
#6 0x080f930b in yyexplain_not_compatible (a=0x831697c, b=0x8447078, flags=0)
at /home/nilsson/Pike/7.5/src/program.c:7789
#7 0x080f930b in yyexplain_not_compatible (a=0x831697c, b=0x8447078, flags=0)
at /home/nilsson/Pike/7.5/src/program.c:7789
#8 0x080f930b in yyexplain_not_compatible (a=0x831697c, b=0x8447078, flags=0)
```
...Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3577Mysql library glue uses incorrect memory management2009-04-16T14:11:39ZPeter BortasMysql library glue uses incorrect memory managementImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3577
Reported by Stephen R. van den Berg, Cubic Circle <srb@cuci.nl>
This bug has been discussed at length on the Pike mailinglist.
It was confirmed by the designer of th...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3577
Reported by Stephen R. van den Berg, Cubic Circle <srb@cuci.nl>
This bug has been discussed at length on the Pike mailinglist.
It was confirmed by the designer of the sql-library-interface that this
patch indeed fixes a flaw in the implementation of the mysql-glue.
It was also noted that quite some implementations (wrongly) seem to depend
on the misguided old behaviour of the lib.
Consensus was that there might be a need to have a bug-compatibility flag
to reinstate the old behaviour.Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3507Global #defines don't propagate in version compat.2009-04-16T14:11:39ZPeter BortasGlobal #defines don't propagate in version compat.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3507
Reported by @grubba
```
$ pike -DFOOBAR=GAZONK
Pike v7.5 release 12 running Hilfe v3.5 (Incremental Pike Frontend)
> FOOBAR;
Compiler Error: 1:Undefined identifier "...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3507
Reported by @grubba
```
$ pike -DFOOBAR=GAZONK
Pike v7.5 release 12 running Hilfe v3.5 (Incremental Pike Frontend)
> FOOBAR;
Compiler Error: 1:Undefined identifier "GAZONK".
Terminal closed.
$ pike -DFOOBAR=GAZONK -V7.4
Pike v7.5 release 12 running Hilfe v3.5 (Incremental Pike Frontend)
> FOOBAR;
Compiler Error: 1:Undefined identifier "FOOBAR".
Terminal closed.
```Pike 7.6Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3465Mysql use mysql_store_result() instead of mysql_use_result()2009-04-16T14:11:39ZPeter BortasMysql use mysql_store_result() instead of mysql_use_result()Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3465
Reported by Stephen R. van den Berg, Cubic Circle <srb@cuci.nl>
The implementation of the Mysql.so module uses the mysql_store_result()
function to actually obtain t...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3465
Reported by Stephen R. van den Berg, Cubic Circle <srb@cuci.nl>
The implementation of the Mysql.so module uses the mysql_store_result()
function to actually obtain the result from the database. This will always
result in the full query being allocated in memory.
This is *not* good, of course.
The intention was that the fetch_row primitives actually do something
usefull. Merely using mysql_use_result() instead of mysqL_store_result()
will result in overall lower memory requirements and increased speed
(needless to say, since Roxen leans heavily on Mysql internally, it seems
rather silly that this was never corrected before).Pike 7.2Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3441global. coredump2011-02-08T11:56:13ZPeter Bortasglobal. coredumpImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3441
Reported by Johan H Sundström, IDA <jhs@pike.ida.liu.se>
This code produces a coredumpwith pike 7.4 at pelix:
```
int a;
int main()
{
int b;
b += global.a;
}
``...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3441
Reported by Johan H Sundström, IDA <jhs@pike.ida.liu.se>
This code produces a coredumpwith pike 7.4 at pelix:
```
int a;
int main()
{
int b;
b += global.a;
}
```
Substituting "+=" for "=" instead renders the error:
```
core.pike:5:Assigning a void expression.
Pike: Failed to compile script:
Compilation failed.
```Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3438Bad data to decode_value crashes pike2009-04-16T14:11:39ZPeter BortasBad data to decode_value crashes pikeImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3438
Reported by Stefan Wallström <stewa@lysator.liu.se>
```
decode_value("¶ke0\1\2\6\7__edit_flag`h\6\0page`f1\6\n__sb_edit_area`&\6\7cge`fn\6e1eli_\5oxie&_ireeet`t`t\6x...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3438
Reported by Stefan Wallström <stewa@lysator.liu.se>
```
decode_value("¶ke0\1\2\6\7__edit_flag`h\6\0page`f1\6\n__sb_edit_area`&\6\7cge`fn\6e1eli_\5oxie&_ireeet`t`t\6xd\0soe`e1eli_`\6\0al`t`t\6x\6\6m0lmrl_f`r");
/home/stewa/Pike7.2/src/encode.c:1527: Fatal error:
error in type string.
Attempting to dump backlog (may fail)...
Backtrace at time of fatal:
Optimizer:0: ___Foo4711()
/usr/local/pike/7.2.462/lib/master.pike:208: master()->compile_string()
```Pike 7.2Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3435Unexpected error from thread function: 62009-04-16T14:11:39ZPeter BortasUnexpected error from thread function: 6Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3435
Reported by Tomas Nilsson, exRoxen <tomas.nilsson@roxen.com>
Pike 7.2 on Windows XP fails with the messages below.
The error does not occur with sources from 2003-05...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3435
Reported by Tomas Nilsson, exRoxen <tomas.nilsson@roxen.com>
Pike 7.2 on Windows XP fails with the messages below.
The error does not occur with sources from 2003-05-06.
```
H:\tmp>pike72n
Pike v7.2 release 496 running Hilfe v2.0 (Incremental Pike Frontend)
> system.gethostbyname("pyton");
\codework\pike\72o\src\threads.c:38: Fatal error:
Unexpected error from thread function: 6
Attempting to dump backlog (may fail)...
Backtrace at time of fatal:
system: gethostbyname("pyton")
-:1: ___Foo4711()
h:/codework/pike/72o/lib/modules/Tools.pmod/Hilfe.pmod:112:
do_evaluate("mixed _
__Foo4711() { return (mixed)(system.gethostbyname(\"pyton\")); }\n",1)
h:/codework/pike/72o/lib/modules/Tools.pmod/Hilfe.pmod:624:
parse_statement("sys
tem.gethostbyname(\"pyton\");")
h:/codework/pike/72o/lib/modules/Tools.pmod/Hilfe.pmod:402: do_parse()
h:/codework/pike/72o/lib/modules/Tools.pmod/Hilfe.pmod:244:
add_buffer("system.g
ethostbyname(\"pyton\");\n")
h:/codework/pike/72o/lib/modules/Tools.pmod/Hilfe.pmod:644:
add_input_line("syst
em.gethostbyname(\"pyton\");\n")
h:/codework/pike/72o/lib/modules/Tools.pmod/Hilfe.pmod:724: create()
Hilfe: StdinHilfe()
```
H:\tmp>Pike 7.2Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3415Probable code-generator bug caught in F_APPLY.2009-04-16T14:11:39ZPeter BortasProbable code-generator bug caught in F_APPLY.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3415
Reported by Jeff Utter, <funk@softhome.net>
Hello, i'm using Caudium 1.3 w/ Pike 7.4.21 It seems theres a bug in
interpert.c that causes pike to segfault often.. her...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3415
Reported by Jeff Utter, <funk@softhome.net>
Hello, i'm using Caudium 1.3 w/ Pike 7.4.21 It seems theres a bug in
interpert.c that causes pike to segfault often.. here's the gdb output:
```
Program received signal SIGSEGV, Segmentation fault.
0x0806e0ca in low_mega_apply (type=APPLY_SVALUE, args=3, arg1=0x288d90a8,
arg2=0x0) at /root/pike-7.4.21/src/interpret.c:1569
1569 assign_svalue(save_sp,Pike_sp-1);
(gdb) bt
#0 0x0806e0ca in low_mega_apply (type=APPLY_SVALUE, args=3, arg1=0x288d90a8,
arg2=0x0) at /root/pike-7.4.21/src/interpret.c:1569
#1 0x0806c701 in opcode_F_APPLY (arg1=137568256) at interpret_functions.h:1841
#2 0x08a83e18 in ?? ()
#3 0x0806f78d in o_catch (pc=0x88ea711 "¡0X\037\b\203@\034\rÇ\004$¿")
at /root/pike-7.4.21/src/interpret.c:1757
#4 0x0806a436 in opcode_F_CATCH () at interpret_functions.h:1201
#5 0x088ea70d in ?? ()
#6 0x0806f6c0 in mega_apply (type=APPLY_STACK, args=2, arg1=0x0, arg2=0x0)
at /root/pike-7.4.21/src/interpret.c:1713
#7 0x0806f7e4 in f_call_function (args=2)
at /root/pike-7.4.21/src/interpret.c:1777
#8 0x080e7dda in new_thread_func (data=0x8a2cd30)
at /root/pike-7.4.21/src/threads.c:772
#9 0x281f148e in _thread_start () from /usr/lib/libc_r.so.5
```
I'm not much of a C coder at all.. hope this can help someone out.Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3278mixed x={} dumps core2009-04-16T14:11:39ZPeter Bortasmixed x={} dumps coreImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3278
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
bin/pike --gdb -e "mixed x={}"
gives
```
-:1:parse error
Program received signal SIGSEGV, Segmentation f...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3278
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
bin/pike --gdb -e "mixed x={}"
gives
```
-:1:parse error
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 28011)]
recursive_add_call_arg (n=0x0, arg=0x82d1518)
at /home/nilsson/Pike/7.3/src/las.c:1714
1714 switch(n->token)
(gdb) bt
#0 recursive_add_call_arg (n=0x0, arg=0x82d1518)
at /home/nilsson/Pike/7.3/src/las.c:1714
#1 0x0806358c in yyparse () at /home/nilsson/Pike/7.3/src/language.yacc:1777
#2 0x080f11b5 in run_pass1 (c=0x82f0770)
at /home/nilsson/Pike/7.3/src/program.c:5466
#3 0x080f17ed in compile (aprog=0x82f0650, ahandler=0x0, amajor=-1,
aminor=-1, atarget=0x0, aplaceholder=0x0)
at /home/nilsson/Pike/7.3/src/program.c:5731
#4 0x08122691 in f_compile (args=4)
at /home/nilsson/Pike/7.3/src/builtin_functions.c:3225
#5 0x080702d8 in opcode_F_CALL_BUILTIN (arg1=15)
at /home/nilsson/Pike/7.3/src/interpret_functions.h:2050
#6 0x083203f8 in ?? ()
#7 0x08072b00 in mega_apply (type=APPLY_LOW, args=2, arg1=0x82a0618,
arg2=0x52) at /home/nilsson/Pike/7.3/src/interpret.c:1431
#8 0x08073657 in apply (o=0x82a0618, fun=0x8198077 "_main", args=2)
at /home/nilsson/Pike/7.3/src/interpret.c:1734
#9 0x080ca5d1 in main (argc=4, argv=0xbffffa8c)
at /home/nilsson/Pike/7.3/src/main.c:726
#10 0x400c7336 in __libc_start_main (main=0x80c9c30 <main>, argc=4,
ubp_av=0xbffffa8c, init=0x805f96c <_init>, fini=0x81771d0 <_fini>,
rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbffffa7c)
at ../sysdeps/generic/libc-start.c:129
```Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3269Crash in stringbuilder2009-04-16T14:11:39ZPeter BortasCrash in stringbuilderImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3269
Reported by David Hedbor, Idonex / Real Networks <david@hedbor.org>
This crash bug occurs at such an early stage that pike can't run at all. I
see two different resu...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3269
Reported by David Hedbor, Idonex / Real Networks <david@hedbor.org>
This crash bug occurs at such an early stage that pike can't run at all. I
see two different results depending on if I have assembler enabled or not
(I believe that these are the only differences).
```
at /home/neotron/pike/7.3/src/stralloc.c:2050
#1 0x0811783c in append_path_unix (s=0xbffff1a8, path=
{ptr = 0x82e6cc4
"/home/neotron/pike/build/7.3-nodebug-asm/lib/modules/Getopt.pmod", shift =
0}, len=64) at /home/neotron/pike/7.3/src/combine_path.h:73
#2 0x081179be in f_combine_path_unix (args=2)
at /home/neotron/pike/7.3/src/stralloc.h:89
#3 0x0806ecfb in opcode_F_CALL_BUILTIN_AND_RETURN (arg1=-1073745512)
at /home/neotron/pike/7.3/src/interpret_functions.h:2059
#4 0x0831a15a in ?? ()
#5 0x08071510 in mega_apply (type=3221221784, args=-1073745512,
arg1=0xbffff198, arg2=0xbffff198)
at /home/neotron/pike/7.3/src/interpret.c:1415
#6 0x08072139 in apply (o=0x402d7000,
fun=0xbffff198 "\200m.\b\220\034\017\b\001", args=65536)
at /home/neotron/pike/7.3/src/interpret.c:1718
#7 0x080c18fd in main (argc=7, argv=0xbffff3c4)
at /home/neotron/pike/7.3/src/main.c:726
#8 0x400b7082 in __libc_start_main () from /lib/i686/libc.so.6
(gdb) p *s
$1 = {s = 0xbffff198, malloced = 256, known_shift = 0}
(gdb) p *s->s
$2 = {refs = 137260416, size_shift = 135208080, len = 1, hval = 27,
next = 0xbffff198, str = ""}
and without assembler
Starting program: /home/neotron/pike/build/7.3-nodebug/pike
-m/home/neotron/pike/build/7.3-nodebug/master.pike
/home/neotron/pike/7.3/bin/test_pike.pike --no-watchdog -a -v -v
/home/neotron/pike/7.3/src/stralloc.c:155: Fatal error:
Breakpoint 1, debug_fatal (fmt=0x1 <Address 0x1 out of bounds>)
at /home/neotron/pike/7.3/src/error.c:371
371 if (in_fatal)
(gdb) cont
Continuing.
Illegal shift size!
Attempting to dump backlog (may fail)...
Unrecognized backtrace format: combine_path_with_cwd
```
Program received signal SIGABRT, Aborted.
Mandrake Cooker, gcc 3.2Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3147indices(Standards) yields coredump.2009-04-16T14:11:39ZPeter Bortasindices(Standards) yields coredump.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3147
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
Doing indices(standards); produces a coredump in my Pike. I have an
uncommitted module (RDF.pike) in the st...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3147
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
Doing indices(standards); produces a coredump in my Pike. I have an
uncommitted module (RDF.pike) in the standards directory, but it works.
```
Pike v7.3 release 47 running Hilfe v3.4 (Incremental Pike Frontend)
> indices(Standards);
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 6259)]
0x4012da9b in strlen (str=0x1 <Address 0x1 out of bounds>)
at ../sysdeps/i386/strlen.c:28
28 ../sysdeps/i386/strlen.c: No such file or directory.
in ../sysdeps/i386/strlen.c
(gdb) bt
#0 0x4012da9b in strlen (str=0x1 <Address 0x1 out of bounds>)
at ../sysdeps/i386/strlen.c:28
#1 0x080f7b00 in debug_make_shared_string (
str=0x1 <Address 0x1 out of bounds>)
at /home/nilsson/Pike/7.3/src/stralloc.c:871
#2 0x080ed071 in debug_start_new_program (line=135871110,
file=0x1 <Address 0x1 out of bounds>)
at /home/nilsson/Pike/7.3/src/program.c:1800
#3 0x403a3dea in pike_module_init ()
at /home/nilsson/Pike/7.3/src/modules/Gz/zlibmod.c:535
#4 0x080aa81d in f_load_module (args=1)
at /home/nilsson/Pike/7.3/src/dynamic_load.c:458
#5 0x0832a293 in ?? ()
#6 0x08072790 in mega_apply (type=APPLY_LOW, args=3, arg1=0x82c9a38,
arg2=0x46) at /home/nilsson/Pike/7.3/src/interpret.c:1409
#7 0x08072dbc in low_unsafe_apply_handler (fun=0x819bb23 "resolv",
handler=0x83cf200, compat=0x0, args=3)
at /home/nilsson/Pike/7.3/src/interpret.c:1607
#8 0x08073049 in safe_apply_handler (fun=0x819bb23 "resolv",
handler=0x83cf200, compat=0x0, args=3, rettypes=0)
at /home/nilsson/Pike/7.3/src/interpret.c:1666
#9 0x080eb987 in resolve_identifier (ident=0x82eaf68)
at /home/nilsson/Pike/7.3/src/program.c:1066
#10 0x080eb7ef in find_module_identifier (ident=0x82eaf68, see_inherit=1)
at /home/nilsson/Pike/7.3/src/program.c:1027
#11 0x08066500 in yyparse () at
/home/nilsson/Pike/7.3/src/language.yacc:3361
#12 0x080f1655 in run_pass1 (c=0x82ec720)
at /home/nilsson/Pike/7.3/src/program.c:5459
#13 0x080f1c6b in compile (aprog=0x864b4c0, ahandler=0x83cf200, amajor=-1,
aminor=-1, atarget=0x8359934, aplaceholder=0x8341938)
at /home/nilsson/Pike/7.3/src/program.c:5720
#14 0x08122df1 in f_compile (args=6)
at /home/nilsson/Pike/7.3/src/builtin_functions.c:3231
#15 0x08070008 in opcode_F_CALL_BUILTIN (arg1=15)
at /home/nilsson/Pike/7.3/src/interpret_functions.h:2046
#16 0x08328fbe in ?? ()
#17 0x0807286b in o_catch (
pc=0x8329f02
"??\a!\b\203@\034\022??\a!\b\213\025?\a!\b\211\002\203?\004\211\025?\a!\b\213\025?\a!\b\213R
\201?0")
at /home/nilsson/Pike/7.3/src/interpret.c:1447
#18 0x0806d092 in opcode_F_CATCH ()
at /home/nilsson/Pike/7.3/src/interpret_functions.h:1151
#19 0x08329efe in ?? ()
#20 0x0807286b in o_catch (pc=0x82f9104 "??\a!\b\203@\034\r?\004$\013")
at /home/nilsson/Pike/7.3/src/interpret.c:1447
---Type <return> to continue, or q <return> to quit---
#21 0x0806d092 in opcode_F_CATCH ()
at /home/nilsson/Pike/7.3/src/interpret_functions.h:1151
#22 0x082f9100 in ?? ()
#23 0x08072790 in mega_apply (type=APPLY_LOW, args=0, arg1=0x82c2548,
arg2=0xc)
at /home/nilsson/Pike/7.3/src/interpret.c:1409
#24 0x08073209 in apply_lfun (o=0x82c2548, fun=25, args=0)
at /home/nilsson/Pike/7.3/src/interpret.c:1698
#25 0x080d3533 in object_indices (o=0x82c2548)
at /home/nilsson/Pike/7.3/src/object.c:1375
#26 0x081210d9 in f_indices (args=1)
at /home/nilsson/Pike/7.3/src/builtin_functions.c:2255
#27 0x083f2d59 in ?? ()
#28 0x0807286b in o_catch (
pc=0x8415472
"??\a!\b\203@\034\022??\a!\b\213\025?\a!\b\211\002\203?\004\211\025?\a!\b\213\025?\a!\b\213R
\201?\020")
at /home/nilsson/Pike/7.3/src/interpret.c:1447
#29 0x0806d092 in opcode_F_CATCH ()
at /home/nilsson/Pike/7.3/src/interpret_functions.h:1151
#30 0x0841546e in ?? ()
#31 0x08072790 in mega_apply (type=APPLY_LOW, args=0, arg1=0x82eb690,
arg2=0x11) at /home/nilsson/Pike/7.3/src/interpret.c:1409
#32 0x080d140f in call_pike_initializers (o=0x82eb690, args=0)
at /home/nilsson/Pike/7.3/src/object.c:280
#33 0x080d161d in parent_clone_object (p=0x835b434, parent=0x82fd368,
parent_identifier=24, args=0) at
/home/nilsson/Pike/7.3/src/object.c:345
#34 0x08071521 in low_mega_apply (type=APPLY_LOW, args=0, arg1=0x82fd368,
arg2=0x18) at /home/nilsson/Pike/7.3/src/apply_low.h:199
#35 0x0806fc87 in opcode_F_CALL_OTHER_AND_POP (arg1=131)
at /home/nilsson/Pike/7.3/src/interpret_functions.h:1899
#36 0x0832f9a2 in ?? ()
#37 0x08072790 in mega_apply (type=APPLY_LOW, args=2, arg1=0x82c9a38,
arg2=0x51) at /home/nilsson/Pike/7.3/src/interpret.c:1409
#38 0x08073267 in apply (o=0x82c9a38, fun=0x8198497 "_main", args=2)
at /home/nilsson/Pike/7.3/src/interpret.c:1710
#39 0x080ca8e1 in main (argc=2, argv=0xbffffa9c)
at /home/nilsson/Pike/7.3/src/main.c:716
#40 0x400c7316 in __libc_start_main (main=0x80c9f50 <main>, argc=2,
ubp_av=0xbffffa9c, init=0x805f854 <_init>, fini=0x8177740 <_fini>,
rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbffffa8c)
at ../sysdeps/generic/libc-start.c:129
```Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3117Pike fails to detect nonblocking method on OpenBSD2009-04-16T14:11:39ZPeter BortasPike fails to detect nonblocking method on OpenBSDImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3117
Reported by @grubba
```
From: Anders Arnholm <anders@arnholm.nu>
To: Henrik Grubbström <grubba@roxen.com>
Date: Mon, 27 May 2002 18:13:15 +0200
Subject: Re: [Bug 310...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3117
Reported by @grubba
```
From: Anders Arnholm <anders@arnholm.nu>
To: Henrik Grubbström <grubba@roxen.com>
Date: Mon, 27 May 2002 18:13:15 +0200
Subject: Re: [Bug 3105] Changed - Pike fails to find pthreads on OpenBSD
```
One more update and I did get that fix too, while your at it, there is
one more thing with autoconf on OpenBSD:
```
/home/balp/src/pike-7.3/Pike/7.3/src/fd_control.c:102: #error Do not
know how to set your filedescriptors nonblocking.
#define USE_FCNTL_O_NONBLOCK
```
Does work, but I don't know how to test for that. But I think I have an
ugly patch. That fixes that problem. (I think, but my network connection
today is a loot shaky so I don't know if the testing worked.)
```
Index: src/configure.in
===================================================================
RCS file: /cvs/Pike/7.3/src/configure.in,v
retrieving revision 1.588
diff -c -r1.588 configure.in
*** src/configure.in 2002/05/27 11:29:29 1.588
--- src/configure.in 2002/05/27 13:46:06
***************
*** 4838,4843 ****
--- 4838,4846 ----
if test "$pike_cv_sys_os" = "AmigaOS" ; then
pike_cv_sys_nonblock=USE_FCNTL_O_NONBLOCK
else
+ if test "$pike_cv_sys_os" = "OpenBSD" ; then
+ pike_cv_sys_nonblock=USE_FCNTL_O_NONBLOCK
+ else
OCPPFLAGS="$CPPFLAGS"
pike_cv_sys_nonblock=UNKNOWN
for method in USE_FCNTL_FNDELAY USE_FCNTL_O_NDELAY
USE_FCNTL_O_NONBLOCK \
***************
*** 4864,4869 ****
--- 4867,4873 ----
done
# Restore CPPFLAGS
CPPFLAGS="$OCPPFLAGS"
+ fi
fi
])
```
/ Anders.Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/3110Protocols.HTTP.Server problem with the Calendar module2022-08-28T23:26:34ZPeter BortasProtocols.HTTP.Server problem with the Calendar moduleImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3110
Reported by Marek Habersack, The Caudium Group <grendel@caudium.net>
when Pike is installed with the --traditional parameter passed to
install.pike, the line below (...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3110
Reported by Marek Habersack, The Caudium Group <grendel@caudium.net>
when Pike is installed with the --traditional parameter passed to
install.pike, the line below (given either in a script or in hilfe) gives a
longish backtrace (see the attachment):
```
Protocols.HTTP.Server.http_date(1);
```
The function above contains the following code:
```
Calendar.ISO_UTC.Second(time)->format_http();
```
When the offending line is preceeded by executing the above code by hand,
the backtrace doesn't occur. Since ISO_UTC is a 'magic' index in the
Calendar module, I suppose there's some confusion with path resolving,
although I cannot find the reason why this is happening. When Pike is
installed with the --new-style (the default) parameter, nothing of the
above occurs.Pike 9.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbström