pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2009-04-16T14:11:39Zhttps://git.lysator.liu.se/pikelang/pike/-/issues/1887Backtrace in Tools.AutoDoc.ProcessXML.moveImages.2009-04-16T14:11:39ZPeter BortasBacktrace in Tools.AutoDoc.ProcessXML.moveImages.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1887
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
(Well, not really, since the error handler in AutoDoc hides backtraces...)
moveImages throws when processi...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1887
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
(Well, not really, since the error handler in AutoDoc hides backtraces...)
moveImages throws when processing autodoc/build/src/modules/Mird/module.xml
due to a docgroup lacking a child with name attribute (contains inherit
elements).Pike 7.4https://git.lysator.liu.se/pikelang/pike/-/issues/1326Backtraces go back past call outs2013-08-29T14:38:11ZPeter BortasBacktraces go back past call outsImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1326
Reported by Martin Stjernholm <mast@roxen.com>
With the new backend system, backtraces in call outs give info that is not
part of their context. E.g:
```
int ma...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1326
Reported by Martin Stjernholm <mast@roxen.com>
With the new backend system, backtraces in call outs give info that is not
part of their context. E.g:
```
int main()
{
call_out (lambda () {error ("foo\n");}, 0);
return -1;
}
```
produces:
```
foo
/home/mast/foo.pike:3: __lambda_65590_0()
backend.cmod:2095: `()(3600.000000)
```
Note the backend.cmod frame. The backtrace also contains the _main frame,
but describe_backtrace doesn't write that one out. I consider this an error
since those frames are not part of the caller context for the call out; a
call out is always called without such a context, just like a function
started in a thread.
The function _do_call_outs also exhibits this:
```
int main()
{
call_out (lambda () {error ("foo\n");}, 0);
_do_call_outs();
}
```
produces:
```
foo
/home/mast/foo.pike:3: __lambda_65590_0()
backend.cmod:2095: _do_call_outs()
/home/mast/foo.pike:4: main()
```
(This might also cause security problems in sandbox situations, since a
sandboxed function could use backtrace() to get references to objects
outside its restricted environment.)Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/2117Backtraces in the debug log when using ssl on nt2009-04-16T14:11:39ZPeter BortasBacktraces in the debug log when using ssl on ntImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2117
Reported by Martin Stjernholm <mast@roxen.com>
I get backtraces like these when I connect with ssl on nt:
```
Cannot access global variables in destructed object.
/...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2117
Reported by Martin Stjernholm <mast@roxen.com>
I get backtraces like these when I connect with ssl on nt:
```
Cannot access global variables in destructed object.
/Program Files/Roxen Internet Software/WebServer/server-
2.2.172/protocols/http.pike:1017: unknown function(0)
pike/lib/pike/modules/SSL.pmod/sslfile.pike:395: ssl_close_callback(0)
pike/lib/pike/modules/Stdio.pmod/module.pmod:698: Stdio.File
("socket", "194.52.182.230 1054", 777 /* fd=-1 */)->__stdio_read_callback()
```
There are no effects (like broken images) on the client side.Pike 7.2https://git.lysator.liu.se/pikelang/pike/-/issues/3614Backtrace when copying roxen-files2009-04-16T14:11:39ZPeter BortasBacktrace when copying roxen-filesImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3614
Reported by Marcus Wellhardh <wellhard@roxen.com>
Got the following when copying /roxen-files to /roxen-files-copy in Roxen
CMS 3.4.128:
```
cvs.exe add: use 'cvs.e...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3614
Reported by Marcus Wellhardh <wellhard@roxen.com>
Got the following when copying /roxen-files to /roxen-files-copy in Roxen
CMS 3.4.128:
```
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away sc_res_infosingle_uc.gif; it is in the way
cvs.exe status: use `cvs.exe add' to create an entry for middle_uc.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away middle_uc.gif; it is in the way
cvs.exe status: use `cvs.exe add' to create an entry for mailto_old.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away mailto_old.gif; it is in the way
cvs.exe status: use `cvs.exe add' to create an entry for middle_old.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away middle_old.gif; it is in the way
cvs.exe status: use `cvs.exe add' to create an entry for middle.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away middle.gif; it is in the way
cvs.exe status: use `cvs.exe add' to create an entry for mailto.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away mailto.gif; it is in the way
cvs.exe status: use `cvs.exe add' to create an entry for free.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away free.gif; it is in the way
[...]
cvs.exe status: nothing known about __info
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe status: use `cvs.exe add' to create an entry for search.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away search.gif; it is in the way
cvs.exe status: use `cvs.exe add' to create an entry for reserve.gif
cvs.exe add: use 'cvs.exe commit' to add this file permanently
cvs.exe update: move away reserve.gif; it is in the way
: "C:/Roxen
CMS/3.4.128/Basic.sb/wa/view/roxen-files-copy/i-icons/intr
abook/help/en/reserve.gif" is invalid or modified - trying to repair.
: Internal server error: Couldn't create pipe: Error 10035
18:06:42 : /${PIKE_MODULE_PATH}/VC.pmod/CVS.pmod/CVS.pike:105:
command(0,"c:/ro
xen
cms/3.4.128/server-3.4.128/modules/sitebuilder/bin/cvs.exe","-!","-q","-d:lo
cal:C:/Roxen CMS/3.4.128/Basic.sb/cvsroot","-n","status","-v","reserve.gif")
0d 1h 9m : /${PIKE_MODULE_PATH}/VC.pmod/CVS.pmod/file.pike:378: status(1)
: /${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/VCFile.pike:1064:
VCFi
le(E/E:2:[Basic]::/roxen-files-copy/i-icons/intrabook/help/en/reserve.gif)->ensu
re_faked()
: /${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/VCFile.pike:2636:
VCFi
le(E/E:2:[Basic]::/roxen-files-copy/i-icons/intrabook/help/en/reserve.gif)->_act
ual_commit(,,,2)
: /${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/VCFile.pike:2733:
VCFi
le(E/E:2:[Basic]::/roxen-files-copy/i-icons/intrabook/help/en/reserve.gif)->comm
it(@0,"Test",0,0)
:
/${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/SBCurrentDir.pike:373:
NoVCDir(E:2:[Basic]::/roxen-files/i-icons/intrabook/help/en)->copy(@0,VCDir(E:2
:[Basic]::/roxen-files-copy/i-icons/intrabook/help/en),"Test",0)
18:06:42 :
/${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/SBCurrentDir.pike:371:
NoVCDir(E:2:[Basic]::/roxen-files/i-icons/intrabook/help)->copy(@0,VCDir(E:2:[B
asic]::/roxen-files-copy/i-icons/intrabook/help),"Test",0)
0d 1h 9m :
/${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/SBCurrentDir.pike:371:
NoVCDir(E:2:[Basic]::/roxen-files/i-icons/intrabook)->copy(@0,VCDir(E:2:[Basic]
::/roxen-files-copy/i-icons/intrabook),"Test",0)
:
/${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/SBCurrentDir.pike:371:
NoVCDir(E:2:[Basic]::/roxen-files/i-icons)->copy(@0,VCDir(E:2:[Basic]::/roxen-f
iles-copy/i-icons),"Test",0)
:
/${PIKE_MODULE_PATH}/Sitebuilder.pmod/FS.pmod/SBCurrentDir.pike:371:
NoVCDir(E:2:[Basic]::/roxen-files)->copy(@0,VCDir(E:2:[Basic]::/roxen-files-cop
y),"Test",0)
: c:/roxen
cms/3.4.128/server-3.4.128/modules/sitebuilder/tabs/files/w
izards/copy.pike (version 1.25):264:
wizard_done(@0,@1=NoVCDir(E:2:[Basic]::/rox
en-files))
: /roxen cms/3.4.128/server-3.4.128/base_server/wizard.pike
(version 1
.143):674: wizard_for(@0,"/edit/!!/!!files!N!ct!!!1078160662«/",@1)
18:06:42 : c:/roxen
cms/3.4.128/server-3.4.128/modules/sitebuilder/tabs/files/w
izards/_wizardbase.pike (version 1.38):259:
wizard_for(@0,"/edit/!!/!!files!N!ct
!!!1078160662«/",@1)
0d 1h 9m : /roxen cms/3.4.128/server-3.4.128/base_server/wizard.pike
(version 1
.143):959: wizard_menu(@0,"c:/roxen
cms/3.4.128/server-3.4.128/modules/sitebuild
er/tabs/files/wizards/","/edit/!!/!!files!N!ct!!!1078160662«/",@1)
: c:/roxen
cms/3.4.128/server-3.4.128/modules/sitebuilder/modules/mana
ger/content_editor.pike (version 1.328):975: show(@0,"wizards/",({c:/roxen
cms/3
.4.128/server-3.4.128/modules/sitebuilder/modules/manager/content_editor.pike.Ta
b(),,,5}))
: c:/roxen
cms/3.4.128/server-3.4.128/modules/sitebuilder/modules/mana
ger/content_editor.pike (version 1.328):2065:
RoxenModule(Basic/content_editor#0
)->find_file("!!roxen-files!!files!N!ct!/!!1078160653-«/wizards/",@0)
: /roxen
cms/3.4.128/server-3.4.128/base_server/configuration.pike (ve
rsion 1.535):1545: Configuration(Basic)->low_get_file(@0,0)
: /roxen
cms/3.4.128/server-3.4.128/base_server/configuration.pike (ve
rsion 1.535):1772: Configuration(Basic)->get_file(@0,0,0)
18:06:42 : /roxen
cms/3.4.128/server-3.4.128/base_server/configuration.pike (ve
rsion 1.535):1736: Configuration(Basic)->handle_request(@0)
0d 1h 9m : /roxen cms/3.4.128/server-3.4.128/protocols/http.pike (version
1.410
):1849:
RequestID(/edit/!!roxen-files!!files!N!ct!/!!1078160653%C2%AE/wizards/?m
agic_roxen_automatic_charset_variable=%E5%E4%F6%26%2333439%3B&action=copy.pike&_
page=1&_state=eJw1jk1OwzAQRlVAgwpU5QgYpIpNlUSBUsSiN%2BAKtmtPUquOHfmH0AuxpDtOBByB
NU6rSLOYGb1P%0D%0A7%2FvaYj66hHFn3bbStqONlcjuYSKV52uNtON0HUOwhm3gQiqHIli3O2J7mA5Y
9OgGcA9jzU0deY1H%0D%0AbgUj2qaLVQWA4EagptFpBjcZShUyQtJUSqMnr0QEQkiRPy2LRb54XH5mv7
TSbAYnqUngNZtO4Hqw%0D%0A9mnraGvb2PbaaCRqDIP2wzfJfSrRh9S8T571u%2BENMrhy9h3N%2FKCd
C9vu4LbhtRL08Kc8BtvwkG6x%0D%0A4c5joG%2Fcqd7K4Pzn%2B292V5YP5fPLP%2BZ7cB4%3D&commi
tmsg=Test&ok=+Ok+)->handle_request()
: /roxen cms/3.4.128/server-3.4.128/base_server/roxen.pike
(version 1.
838):631: roxen->handler_thread(2)
:
: Persistent cache: Prefetch crawler finished after 00:02:30
: Started indexing: Basic
: Starting Search Crawler (pid 3444).
18:11:04 : Finished indexing: Basic
```Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/5730Backtrace when Protocols.HTTP.Query objects are cleaned up2010-10-12T20:07:36ZPeter BortasBacktrace when Protocols.HTTP.Query objects are cleaned upImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5730
Reported by Martin Stjernholm <mast@roxen.com>
These occur regurlarly when the refcount garb frees Protocols.HTTP.Query objects:
```
File not open.
-:1: Fd(-49)->se...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5730
Reported by Martin Stjernholm <mast@roxen.com>
These occur regurlarly when the refcount garb frees Protocols.HTTP.Query objects:
```
File not open.
-:1: Fd(-49)->set_nonblocking()
-:1: Stdio.File("socket", "152.90.238.80:443", 777 /* fd=-1 */)->set_nonblocking()
C:/Program Files (x86)/Pike/lib/modules/Stdio.pmod/module.pmod:1374: Stdio.File("socket", "152.90.238.80:443", 777 /* fd=-1 */)->set_nonblocking(UNDEFINED,UNDEFINED,UNDEFINED,UNDEFINED,UNDEFINED)
C:/Program Files (x86)/Pike/lib/modules/Protocols.pmod/HTTP.pmod/Query.pike:1168: Protocols.HTTP.Query()->close()
C:/Program Files (x86)/Pike/lib/modules/Protocols.pmod/HTTP.pmod/Query.pike:1160: Protocols.HTTP.Query()->destroy()
... the rest of the backtrace is unrelated
```
Some cvs digging points at this commit:
revision 1.106
date: 2010/03/12 10:18:34; author: srb; state: Exp; lines: +20 -19
Expose close() so you do not have to wait for garbage collection.
It removes a few catches in the destroy() function. Apparently they are there for a reason, but hopefully it's possible to solve the problem in a less blunt way.Pike 7.8https://git.lysator.liu.se/pikelang/pike/-/issues/8173Bad assignment in Protocols.HTTP.Server.Request2019-03-06T10:05:51ZPeter BortasBad assignment in Protocols.HTTP.Server.RequestImported from https://youtrack.roxen.com/issue/PIKE-173
Reported by @grubba
`low_make_response_header()` attempts to assign a non-existent variable `error` in a `Stdio.Buffer` object.Imported from https://youtrack.roxen.com/issue/PIKE-173
Reported by @grubba
`low_make_response_header()` attempts to assign a non-existent variable `error` in a `Stdio.Buffer` object.https://git.lysator.liu.se/pikelang/pike/-/issues/1370Bad autodoc dump error message2009-04-16T14:11:39ZPeter BortasBad autodoc dump error messageImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1370
Reported by Johan H Sundström, IDA <jhs@pike.ida.liu.se>
This broken markup:
/*! @decl int exece(string file, array(string) args,
*! mapping(string...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1370
Reported by Johan H Sundström, IDA <jhs@pike.ida.liu.se>
This broken markup:
/*! @decl int exece(string file, array(string) args,
*! mapping(string:string) env)
(a forgotten "@" at the end of the first line) ends up with this fairly
incomprehensible error message:
```
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/PikeParser.pike:102:
parseError("Expected type, idents or literal constant")
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/PikeParser.pike:428:
parseArgList(1)
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/PikeParser.pike:567:
parseDecl(mapping[2])
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/DocParser.pmod:706:
getMetaData()
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/DocParser.pmod:837:
metadata()
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/CExtractor.pmod:79:
parseObject()
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/CExtractor.pmod:149:
parseClassBody(,,,0)
/i/pike/7.3.2/lib/modules/Tools.pmod/AutoDoc.pmod/CExtractor.pmod:174:
extract("/*\\\n||| This file a part of Pike, and is copyright by
Fredrik Hubinette\n||| Pike is distributed as GPL (General Public
License)\n||| See the files COPYING "+[29596],"../../.
./../../src/modules/files/efuns.c")
/home/jhs/Pike/7.3/bin/autodoc.pike:30:
main(2,({"/home/jhs/Pike/7.3/bin/autodoc.pike","../../../../../src/modules/files/efuns.c"}))
Lookup on non-string value.
/home/jhs/Pike/7.3/bin/autodoc.pike:11:
main(2,({"/home/jhs/Pike/7.3/bin/autodoc.pike","../../../../../src/modules/files/efuns.c"}))
```Pike 7.6https://git.lysator.liu.se/pikelang/pike/-/issues/5Bad handling of EOF in Stdio.FILE.gets()2009-04-16T14:11:39ZPeter BortasBad handling of EOF in Stdio.FILE.gets()Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5
Reported by @grubba
```
From: Aleph One <aleph1@underground.org>
To: pike@idonex.se
Date: Tue, 11 Jul 2000 12:28:15 -0700
Subject: Stdio.FILE.gets()
```
There is a bug...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5
Reported by @grubba
```
From: Aleph One <aleph1@underground.org>
To: pike@idonex.se
Date: Tue, 11 Jul 2000 12:28:15 -0700
Subject: Stdio.FILE.gets()
```
There is a bug in the Stdio.FILE.gets() functions. The standard C library
gets() function will read bytes until a terminating newline or an EOF.
If it reaches the EOF it will replace the EOF by a null char and return
the last "unterminated" last line. If you read again it returns NULL.
Pike's Stdio.FILE.gets() fails to return the last line of a file unless
its terminated by a newline character.
```
string gets()
{
int p,tmp=0;
while((p=search(b, "\n", bpos+tmp)) == -1)
{
tmp=strlen(b)-bpos;
if(!get_data()) return 0;
}
return extract(p-bpos, 1);
}
```
should be something like:
```
string gets()
{
int p,tmp=0;
while((p=search(b, "\n", bpos+tmp)) == -1)
{
tmp=strlen(b)-bpos;
if(!get_data())
{
if (bpos == sizeof(b))
return 0;
else
return extract(sizeof(b)-bpos, 0);
}
}
return extract(p-bpos, 1);
}
```
Comments?
--
Aleph One / aleph1@underground.org
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01Pike 7.0https://git.lysator.liu.se/pikelang/pike/-/issues/953bad implemented list_fields() for postgress and msql2009-04-16T14:11:39ZPeter Bortasbad implemented list_fields() for postgress and msqlImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=953
Reported by Jordi Murgó, The Apostols Unix Cult <jordi@lleida.com>
while in Sql.pmod/sql.pike you declare list_fields as follows:
```
array(mapping(string:mixed)) li...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=953
Reported by Jordi Murgó, The Apostols Unix Cult <jordi@lleida.com>
while in Sql.pmod/sql.pike you declare list_fields as follows:
```
array(mapping(string:mixed)) list_fields(string table, string|void wild)
{
array(mapping(string:mixed))|object res;
if (functionp(master_sql->list_fields)) {
if (objectp(res = master_sql->list_fields(table))) {
res = res_obj_to_array(res);
}
....
```
on postgres.pike and msql.pike the same funcion are declared as:
mapping(string:array(mixed)) list_fields (string table, void|string wild)
I think it should be rewriten and declared:
array(mapping(string:mixed)) list_fields (string table)
(wild is not really needed)Pike 7.2Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/4855"Bad offset" when generating backtrace2009-06-17T17:42:07ZPeter Bortas"Bad offset" when generating backtraceImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4855
Reported by Jonas Wallden <jonasw@roxen.com>
```
class Abstract {
void foo();
}
void main()
{
Abstract()->foo();
}
ceylon:~ $ ~/pike/7.8/bin/pike ~/bad-offset...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4855
Reported by Jonas Wallden <jonasw@roxen.com>
```
class Abstract {
void foo();
}
void main()
{
Abstract()->foo();
}
ceylon:~ $ ~/pike/7.8/bin/pike ~/bad-offset.pike
Bad offset: pc:0x6d2194 program:0x6d2198 (0x0)
Calling undefined function.
/main()->Abstract: /main()->Abstract()->foo()
bad-offset.pike:7: /main()->main()
```Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/2792Bad time complexity in free_all_nodes in las.c2009-04-16T14:11:39ZPeter BortasBad time complexity in free_all_nodes in las.cImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2792
Reported by Martin Stjernholm <mast@roxen.com>
free_all_nodes goes through all nodes in the block_alloc blocks and checks
for each one if it's on the free list befor...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2792
Reported by Martin Stjernholm <mast@roxen.com>
free_all_nodes goes through all nodes in the block_alloc blocks and checks
for each one if it's on the free list before freeing it. Since the free
list grows with each freed node, it causes the running time of
free_all_nodes to be O(n^2 + m) where n is the number of allocated nodes
and m is the number of free nodes.
As a specific case, I have a program with a parse error in it. After
reporting the error it takes approximately 15 seconds for free_all_nodes to
run. The free list contains in this case about 19000 nodes and there are 50
nodes to be freed.
I suggest that freed nodes are marked in some way so they can be recognized
immediately.
(Looks like the problem exists in 7.2 too, although I haven't tested it
there.)Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/1770Bogus svalue in object to free2009-04-16T14:11:39ZPeter BortasBogus svalue in object to freeImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1770
Reported by Martin Stjernholm <mast@roxen.com>
In my development Roxen server I get the following error. It seems hard to
minimize, but I have an easily reproducible...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1770
Reported by Martin Stjernholm <mast@roxen.com>
In my development Roxen server I get the following error. It seems hard to
minimize, but I have an easily reproducible case in my setup. (Old dumped
files are ruled out.)
```
/home/mast/Pike/7.2/src/object.c:599: Fatal error:
Type error: 31
Attempting to dump backlog (may fail)...
Backtrace at time of fatal:
Unknown program: unknown function()
module.Context: RXML.Context->handle_exception(({"Indexing the NUL"+[54]+"e
container=\"\">\n",({({"/home/mast/Roxen"+[24]+"erver/roxen.pike",550,@0=roxen->handler_thread,0}),({"/home/mast/Roxen"+[21]+"tocols/http.pike",1858,@1=RequestID()->handle_request}),({"/home/mast/Roxen"+[32]+"nfiguration.pike",1649,@2=Configuration(test)->handle_request,@3=RequestID()}),({"/home/mast/Roxen"+[32]+"nfiguration.pike",1681,@4=Configuration(test)->get_file,@3,0,0}),({"/home/mast/Roxen"+[32]+"nfiguration.pike",1538,@5=Configuration(test)->low_get_file,@3,0}),({"/home/mast/Roxen"+[38]+"directories.pike",206,@6=RoxenModule(test/directories#0)->parse_directory,@3}),({"/home/mast/Roxen"+[32]+"nfiguration.pike",1681,@4,@3,0,0}),({"/home/mast/Roxen"+[32]+"nfiguration.pike",1580,@5,@3,0}),({"/home/mast/Roxen"+[29]+"s/rxmlparse.pike",159,@7=RoxenModule(test/rxmlparse#0)->handle_file_extension,@8=Stdio.File("/home/mast/html/index.html",
"r", 666 /* fd=28
*/),"html",@3}),({"/home/mast/Roxen"+[24]+"dules/Roxen.pmod",765,@9=compile_rxml,"<html>\n<title>fo"+[6608]+"/body>\n\n</html>\n",@3}),/.../
etc/modules/RXML.pmod/module.pmod:428:
RXML.Tag(define)->_p_xml_handle_tag(@14,@15,"<contents/>")
/.../
(gdb) bt
#0 0xdfbce4c9 in __sigprocmask () from /usr/lib/libthread.so.1
#1 0xdfbc5639 in _resetsig () from /usr/lib/libthread.so.1
#2 0xdfbc4fb6 in _sigon () from /usr/lib/libthread.so.1
#3 0xdfbc3134 in _lmutex_unlock () from /usr/lib/libthread.so.1
#4 0xdfbc7547 in _thrp_kill () from /usr/lib/libthread.so.1
#5 0xdfbc7434 in thr_kill () from /usr/lib/libthread.so.1
#6 0xdfabbf87 in raise () from /usr/lib/libc.so.1
#7 0xdfaac334 in abort () from /usr/lib/libc.so.1
#8 0xdedab92d in Abort () from
/i/jdk/1.2.2_006/jre/lib/i386/classic/libjvm.so
#9 0xdedd21ce in panicHandler () from
/i/jdk/1.2.2_006/jre/lib/i386/classic/libjvm.so
#10 0xded7cc53 in userSignalHandler () from
/i/jdk/1.2.2_006/jre/lib/i386/native_threads/libhpi.so
#11 0xded7cc3d in intrDispatch () from
/i/jdk/1.2.2_006/jre/lib/i386/native_threads/libhpi.so
#12 0xded7b77e in intrDispatchMD () from
/i/jdk/1.2.2_006/jre/lib/i386/native_threads/libhpi.so
#13 0xdfbc0343 in __sighndlr () from /usr/lib/libthread.so.1
#14 0xdfbcd43b in sigacthandler () from /usr/lib/libthread.so.1
#15 <signal handler called>
#16 0xdfbce4c9 in __sigprocmask () from /usr/lib/libthread.so.1
#17 0xdfbc4fb6 in _sigon () from /usr/lib/libthread.so.1
#18 0xdfbc3134 in _lmutex_unlock () from /usr/lib/libthread.so.1
#19 0xdfbc7547 in _thrp_kill () from /usr/lib/libthread.so.1
#20 0xdfbc7434 in thr_kill () from /usr/lib/libthread.so.1
#21 0xdfabbf87 in raise () from /usr/lib/libc.so.1
#22 0xdfaac2fb in abort () from /usr/lib/libc.so.1
#23 0x80b7223 in debug_fatal () at /home/mast/Pike/7.2/src/error.c:523
#24 0x80e3362 in low_destruct (o=0x8db4bf4, do_free=1) at
/home/mast/Pike/7.2/src/object.c:599
#25 0x80e352c in destruct (o=0x8db4bf4) at
/home/mast/Pike/7.2/src/object.c:632
#26 0x80e35f8 in destruct_objects_to_destruct () at
/home/mast/Pike/7.2/src/object.c:677
#27 0x80a8291 in call_callback (lst=0x8241994, arg=0x0) at
/home/mast/Pike/7.2/src/callback.c:143
#28 0x8084645 in mega_apply (type=APPLY_STACK, args=2, arg1=0x0, arg2=0x0)
at /home/mast/Pike/7.2/src/interpret.c:1320
#29 0x8082c6e in eval_instruction_without_debug (pc=0x85d0fb6
"EZ\001i\006lH\006EZ\001\030\f")
at /home/mast/Pike/7.2/src/interpret_functions.h:1489
/.../
(gdb won't let me look at the svalue in question; "cannot access memory..."
:\ )
```Pike 7.2Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/2768bogus `type mismatch' warning2022-08-28T23:32:32ZPeter Bortasbogus `type mismatch' warningImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2768
Reported by Robert J. Budzynski, Warsaw University, Dept. of Physics <Robert.Budzynski@fuw.edu.pl>
```
Running the following script (foo.pike):
#!/usr/local/bin/pike...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2768
Reported by Robert J. Budzynski, Warsaw University, Dept. of Physics <Robert.Budzynski@fuw.edu.pl>
```
Running the following script (foo.pike):
#!/usr/local/bin/pike -w
#pragma strict_types
int main(int ac, array(string) av)
{
write(version()+"\n");
int(-1..1) foo=0;
if(ac>1)
{
if(av[1]=="1") foo++;
else foo--;
}
switch(foo)
{
case 1: write("foo is one\n"); break;
case -1: write("foo is minus one\n"); break;
case 0: write("foo is zero\n"); break;
default: write("Bah!\n");
}
return 0;
}
// script ends here
```
I obtain the output
```
$ ./foo.pike xxx
foo.pike:15: Warning: Type mismatch in case.
foo.pike:15: Warning: Expected: int(-1..1)
foo.pike:15: Warning: Got : int
Pike v7.3 release 14
foo is minus one
```Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/8008bool resolves to int(1..1)2017-04-27T13:39:11ZPeter Bortasbool resolves to int(1..1)Imported from https://youtrack.roxen.com/issue/PIKE-8
Reported by KG Sterneberg <kg@roxen.com>
I get the following problem:
```
>pike bool-test.pike
int(1..1)
Bool value: 1
Bad argument 1 to foo(). Expected object | { bool = int(1..1)...Imported from https://youtrack.roxen.com/issue/PIKE-8
Reported by KG Sterneberg <kg@roxen.com>
I get the following problem:
```
>pike bool-test.pike
int(1..1)
Bool value: 1
Bad argument 1 to foo(). Expected object | { bool = int(1..1) }.
bool-test.pike:9: /main()->foo(0)
bool-test.pike:5:
/main()->main(1,({"/Users/kg/dev/learning/pike/bool-test.pike"}))
```
when running:
```
int main(int argc, array(string) argv)
{
werror("%O\n", bool);
foo(true);
foo(false);
return 0;
}
variant void foo(bool v) {
werror("Bool value: %O\n", v);
}
variant void foo(object v) {
werror("Object: %O\n", v);
}
```
Without variant it works fine:
```
int main(int argc, array(string) argv)
{
werror("%O\n", bool);
foo(true);
foo(false);
return 0;
}
void foo(bool v) {
werror("Bool value: %O\n", v);
}
}
```
Possible solution (by Grubba):
In master.pike, replace
```
enum bool { false=0, true=1 };
```
with
```
typedef int(0..1) bool;
enum { false=0, true=1 };
```https://git.lysator.liu.se/pikelang/pike/-/issues/1890both 7.2.110 and 7.3.9 postgres is broken2009-04-16T14:11:39ZPeter Bortasboth 7.2.110 and 7.3.9 postgres is brokenImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1890
Reported by Randall Randall, 3PSecure.com, Ltd. <randall@3psecure.com>
```
when attempting
object db = Sql.sql("postgres://user:@127.0.0.1/db");
this error occurs:
/...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1890
Reported by Randall Randall, 3PSecure.com, Ltd. <randall@3psecure.com>
```
when attempting
object db = Sql.sql("postgres://user:@127.0.0.1/db");
this error occurs:
/usr/local/pike/7.2.110/lib/modules/Sql.pmod/postgres.pike:129:Too many
arguments to big_query.
/usr/local/pike/7.2.110/lib/modules/Sql.pmod/postgres.pike:129:Expected:
function(string : int | object)
/usr/local/pike/7.2.110/lib/modules/Sql.pmod/postgres.pike:129:Got :
function(string, object(implements 65607) : void | mixed)
```
The error is exactly the same for 7.3.9, except for the version number.Pike 7.2https://git.lysator.liu.se/pikelang/pike/-/issues/7384Broken "--" operator on mappings2014-12-05T16:42:44ZPeter BortasBroken "--" operator on mappingsImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7384
Reported by Martin Karlgren <marty@roxen.com>
```
Pike v8.0 release 34 running Hilfe v3.5 (Incremental Pike Frontend)
> mapping m = ([ 4711: 5 ]);
> --m[4711];
(1) R...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7384
Reported by Martin Karlgren <marty@roxen.com>
```
Pike v8.0 release 34 running Hilfe v3.5 (Incremental Pike Frontend)
> mapping m = ([ 4711: 5 ]);
> --m[4711];
(1) Result: 4710
> m;
(2) Result: ([ /* 1 element */
4711: 5
])
Pike v7.8 release 883 running Hilfe v3.5 (Incremental Pike Frontend)
> mapping m = ([ 4711: 5 ]);
> --m[4711];
(1) Result: 4
> m;
(2) Result: ([ /* 1 element */
4711: 4
])
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/944Broken sh-code in GTK module.2009-04-16T14:11:39ZPeter BortasBroken sh-code in GTK module.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=944
Reported by @grubba
```
Making GTK
make[4]: Entering directory
`/tmp/autobuild/pike7.1-20001219170839.tar/build/linux-2.4.0-0.8-ia64/post_modules/GTK'
/tmp/autobuild/...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=944
Reported by @grubba
```
Making GTK
make[4]: Entering directory
`/tmp/autobuild/pike7.1-20001219170839.tar/build/linux-2.4.0-0.8-ia64/post_modules/GTK'
/tmp/autobuild/pike7.1-20001219170839.tar/build/linux-2.4.0-0.8-ia64/pike
-DNOT_INSTALLED
-m/tmp/autobuild/pike7.1-20001219170839.tar/build/linux-2.4.0-0.8-ia64/master.pike
/tmp/autobuild/pike7.1-20001219170839.tar/src/post_modules/GTK/new_build_pgtk.pike
--source='/tmp/autobuild/pike7.1-20001219170839.tar/src/post_modules/GTK/source/'\
/tmp/autobuild/pike7.1-20001219170839.tar/src/post_modules/GTK/output/few.pike
Parsing input files... 7.4s
Checking inherits ...
Outputting result files...
Creating GTK/pgtk_1.c
Creating GTK/pgtk_2.c
Creating GTK/pgtk_3.c
Creating GTK/pgtk_4.c
Creating GTK/pgtk_5.c
Creating GTK/prototypes.h
Creating GTK/time_stamp
Creating GTK/pgtk.c
Total time spent... 12.0s
/bin/sh: -c: line 1: unexpected EOF while looking for matching ``'
/bin/sh: -c: line 2: syntax error: unexpected end of file
make[4]: *** [compile1] Error 2
make[4]: Leaving directory
`/tmp/autobuild/pike7.1-20001219170839.tar/build/linux-2.4.0-0.8-ia64/post_modules/GTK'
make[3]: *** [GTK] Error 1
```Pike 7.2https://git.lysator.liu.se/pikelang/pike/-/issues/461bsd/os 4.x and linkers2009-04-16T14:11:39ZPeter Bortasbsd/os 4.x and linkersImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=461
Reported by eric lindvall, <eric@nack.net>
the configure script choses to use shlicc as LD for all versions of bsd/os.
for using bsd/os 4.x, ld or gcc are better choi...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=461
Reported by eric lindvall, <eric@nack.net>
the configure script choses to use shlicc as LD for all versions of bsd/os.
for using bsd/os 4.x, ld or gcc are better choices. (ld is what is chosen
when you comment shlicc out, and it compiles fine).Pike 7.0https://git.lysator.liu.se/pikelang/pike/-/issues/865Buffer malfunction in Stdio.FILE2009-04-16T14:11:39ZPeter BortasBuffer malfunction in Stdio.FILEImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=865
Reported by Fredrik Noring, Roxen Internet Software <noring@roxen.com>
The following program trigs a bug in Stdio.FILE
```
int verify(string filename, int blocksi...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=865
Reported by Fredrik Noring, Roxen Internet Software <noring@roxen.com>
The following program trigs a bug in Stdio.FILE
```
int verify(string filename, int blocksize, string data)
{
Stdio.File file = Stdio.FILE(filename, "r");
string block, verify = "";
while((block = file->read(blocksize)) != "")
verify += block;
return data == verify;
}
void main()
{
string data = (array(string))enumerate(10)*"\n"+"\n";
Stdio.File("data", "wct")->write(data);
for(int blocksize = 1; blocksize < 20; blocksize++)
write("Verify blocksize %d: %s\n", blocksize,
verify("data", blocksize, data) ? "ok" : "FAIL");
}
```
with the following output
Verify blocksize 1: FAIL
Verify blocksize 2: FAIL
Verify blocksize 3: ok
Verify blocksize 4: FAIL
Verify blocksize 5: FAIL
Verify blocksize 6: ok
Verify blocksize 7: ok
Verify blocksize 8: ok
Verify blocksize 9: ok
Verify blocksize 10: FAIL
Verify blocksize 11: ok
Verify blocksize 12: ok
Verify blocksize 13: ok
Verify blocksize 14: ok
Verify blocksize 15: ok
Verify blocksize 16: ok
Verify blocksize 17: ok
Verify blocksize 18: ok
Verify blocksize 19: okPike 7.2https://git.lysator.liu.se/pikelang/pike/-/issues/1875Bug when using specific type2009-04-16T14:11:39ZPeter BortasBug when using specific typeImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1875
Reported by David Hedbor, Idonex / Real Networks <david@hedbor.org>
When using an object declared as Image.Color obj calling obj->rgb() fails
at compile time. This d...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1875
Reported by David Hedbor, Idonex / Real Networks <david@hedbor.org>
When using an object declared as Image.Color obj calling obj->rgb() fails
at compile time. This does not occur with Pike 7.3. See attached program.Pike 7.0