pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2022-11-06T11:19:16Zhttps://git.lysator.liu.se/pikelang/pike/-/issues/8011wrong variant order can cause exception2022-11-06T11:19:16ZPeter Bortaswrong variant order can cause exceptionImported from https://youtrack.roxen.com/issue/PIKE-11
Reported by KG Sterneberg <kg@roxen.com>
Running the following code:
```
int main(int argc, array(string) argv)
{
array exceptions = ({
Error.mkerror("Ett vanligt fel..."),
...Imported from https://youtrack.roxen.com/issue/PIKE-11
Reported by KG Sterneberg <kg@roxen.com>
Running the following code:
```
int main(int argc, array(string) argv)
{
array exceptions = ({
Error.mkerror("Ett vanligt fel..."),
MyException("Oh no! Something blew up."),
MyError("This is my error"),
"hej hopp gallop",
});
foreach (exceptions, mixed obj) {
handle_error(obj);
}
return 0;
}
variant void handle_error(mixed e) {
werror("Handle an error of unknown type: %O\n", e);
}
variant void handle_error(MyException e) {
werror("Handle an MyException: %s\n", describe_error(e));
}
variant void handle_error(Error.Generic e) {
werror("Handle an Error.Generic: %s\n", describe_error(e));
}
variant void handle_error(MyError e) {
werror("Handle an MyError: %s\n", describe_error(e));
}
class MyException {
inherit Error.Generic;
protected void create(string message) {
::create(message, backtrace());
}
public constant is_my_exception = true;
}
class MyError {
inherit Error.Generic;
protected void create(string message) {
::create(message, backtrace());
}
public constant is_my_error = true;
}
```
results in:
```
>pike exception-test.pike
*Calling undefined function.*
exception-test.pike:27: /main()->handle_error(_static_modules.Builtin()->GenericError("Ett vanligt fel..."))
exception-test.pike:15: /main()->handle_error()
exception-test.pike:10: /main()->main(1,({"/Users/kg/dev/learning/pike/exception-test.pike"}))
```
Just by switching the order of the handle_error variants lite this:
```
variant void handle_error(mixed e) {
werror("Handle an error of unknown type: %O\n", e);
}
variant void handle_error(MyException e) {
werror("Handle an MyException: %s\n", describe_error(e));
}
variant void handle_error(MyError e) {
werror("Handle an MyError: %s\n", describe_error(e));
}
variant void handle_error(Error.Generic e) {
werror("Handle an Error.Generic: %s\n", describe_error(e));
}
```
will make the program work:
```
>pike exception-test.pike
Handle an Error.Generic: Ett vanligt fel...
Handle an MyException: Oh no! Something blew up.
Handle an MyError: This is my error
Handle an error of unknown type: "hej hopp gallop"
```
*This behaviour is dangerous and a potential source of bugs that can be hard do discover.*
P.S. Moving the deklarations of MyException and MyError above the main-function also solves the problem.https://git.lysator.liu.se/pikelang/pike/-/issues/8009Declaration order for nested classes matters - should not!2020-03-23T09:49:57ZPeter BortasDeclaration order for nested classes matters - should not!Imported from https://youtrack.roxen.com/issue/PIKE-9
Reported by KG Sterneberg <kg@roxen.com>
The following code does not work (but it should):
```
int main(int argc, array(string) argv)
{
Outer outer = Outer();
Outer.Nested n = ...Imported from https://youtrack.roxen.com/issue/PIKE-9
Reported by KG Sterneberg <kg@roxen.com>
The following code does not work (but it should):
```
int main(int argc, array(string) argv)
{
Outer outer = Outer();
Outer.Nested n = outer->get_nested();
n->hello_world();
}
class Outer
{
Nested get_nested()
{
return Nested();
}
class Nested
{
void hello_world() { werror("Hello World!\n"); }
}
}
```
Running it:
```
>pike tmp.pike
tmp.pike:4:Indexing on illegal type.
tmp.pike:4:Got : zero.
tmp.pike:4:Index : string(78..116).
tmp.pike:4:Expected constant expression.
Pike: Failed to compile script.
```
Moving "class Outer" above main solves the problem. However the order should not matter!https://git.lysator.liu.se/pikelang/pike/-/issues/8005Image.PS.decode fails on WIN32.2020-03-06T10:51:28ZPeter BortasImage.PS.decode fails on WIN32.Imported from https://youtrack.roxen.com/issue/PIKE-5
Reported by @grubba
REP 6.1.198/Pike 8.0.408:
#### From REPs testsuite
```
Running test C:/disttest/install test/ep_6_1/server-6.1.198/packages/print/test/tests/RoxenTest_rep_imag...Imported from https://youtrack.roxen.com/issue/PIKE-5
Reported by @grubba
REP 6.1.198/Pike 8.0.408:
#### From REPs testsuite
```
Running test C:/disttest/install test/ep_6_1/server-6.1.198/packages/print/test/tests/RoxenTest_rep_imageproc.pike
################ Background failure
Image Processor: Pike Image Processor: image_resize failed to decode ([ /* 3 elements */
"filepath": "C:/disttest/install test/ep_6_1/server-6.1.198/packages/print/test/data/1163486.pdf",
"mimetype": "application/pdf",
"resize": ({ /* 1 element */
([ /* 2 elements */
"filepath": "/tmp/roxentest/output11268.jpg",
"mimetype": "image/jpeg"
])
})
]):
Failed to start process (3).
-:1: _static_modules.Builtin()->create_process()->create(({"/bin/sh -c gs ","-quiet","-sDEVICE=ppmraw","-r100","-dBATCH","-dNOPAUSE","-dUseCIEColor",,,3}),mapping[3])
c:/disttest/install test/ep_6_1/server-6.1.198/pike/lib/modules/_Image_PS.pmod:156: _Image_PS.decode(0,mapping[4])
C:/disttest/install test/ep_6_1/server-6.1.198/packages/imageproc/modules/image-pike.pike (602b93f3):166: RoxenModule(Test REP/image-pike#0)->do_image_resize(mapping[3])
C:/disttest/install test/ep_6_1/server-6.1.198/packages/imageproc/modules/image-pike.pike (602b93f3):126: RoxenModule(Test REP/image-pike#0)->image_resize(mapping[1])
C:/disttest/install test/ep_6_1/server-6.1.198/packages/imageproc/modules/image.pike (3b2788c1):525: RoxenModule(Test REP/image#0)->do_processing(,,,1)
C:/disttest/install test/ep_6_1/server-6.1.198/packages/imageproc/modules/image.pike (3b2788c1):474: RoxenModule(Test REP/image#0)->processor(RoxenModule(Test REP/image#0)->ThreadSafePrioQueue(),0)
| ################ C:/disttest/install test/ep_6_1/server-6.1.198/packages/print/test/tests/RoxenTest_rep_imageproc.pike:36: FAILED
| res
```https://git.lysator.liu.se/pikelang/pike/-/issues/3505Incorrect paths in dumped modules for .so libraries2022-08-28T16:00:50ZPeter BortasIncorrect paths in dumped modules for .so librariesImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3505
Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=210743
Reported by Marek Habersack, The Caudium Group <grendel@caudium.net>
When building Pike in a fake...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3505
Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=210743
Reported by Marek Habersack, The Caudium Group <grendel@caudium.net>
When building Pike in a fakeroot the modules which reference other modules
implemented as .so libraries will have the full path of the fakeroot stored
in the resulting .o file when referencing the .so modules:
/usr/lib/pike/7.4.27/lib/modules/_Charset.pmod.o:-: Warning: Decode failed:
Failed to decode program
"/tmp/buildd/pike7.4-7.4.27/debian/pike7.4-core/usr/lib/pike/7.4.27/lib/modules/____Charset.so".
/usr/lib/pike/7.4.27/lib/modules/Regexp.pmod.o:-: Warning: Decode failed:
Failed to decode program
"/tmp/buildd/pike7.4-7.4.27/debian/pike7.4-core/usr/lib/pike/7.4.27/lib/modules/___Regexp.so".
The error is probably somewhere in the master resolver, but I'm not sure of
that.Pike 9.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7831Unclear http headers case handling in Protocols.HTTP.do_async_method()2022-10-06T12:29:59ZPeter BortasUnclear http headers case handling in Protocols.HTTP.do_async_method()Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7831
Reported by Tobias Liin <liin@roxen.com>
`Protocols.HTTP.do_async_method()` provides default values for http headers `"user-agent"` and `"host"`, if not provided in ...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7831
Reported by Tobias Liin <liin@roxen.com>
`Protocols.HTTP.do_async_method()` provides default values for http headers `"user-agent"` and `"host"`, if not provided in the request_headers variable.
However, it fails to consider the casing of those headers. Consider a call to `do_async_method()` with the following headers mapping:
```
([
"Host": "foo.com",
"User-Agent": "Firefox"
])
```
The mapping provided to `Protocols.HTTP.Query.async_request()` will be:
```
([
"Host": "foo.com",
"User-Agent": "Firefox"
"host": "<some-host-from-the-url>",
"user-agent": "Pike <some-version>",
])
```
The resulting host and user-agent will be random, as `Protocols.HTTP.Query.async_request()` lowercase the indices.
The solution is probably for `Protocols.HTTP.do_async_method()` to lowercase the headers mapping indices before checking for `"host"` and `"user-agent"`.Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7778HTTP Relay module requires ipv6 if remote server has ipv6.2020-03-01T15:51:42ZPeter BortasHTTP Relay module requires ipv6 if remote server has ipv6.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7778
Reported by Jonas Lönnberg <lonnberg@roxen.com>
The HTTP Relay module requires ipv6 if remote server has ipv6.
Example settings:
LOCATION /foo CALL http://www.rox...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7778
Reported by Jonas Lönnberg <lonnberg@roxen.com>
The HTTP Relay module requires ipv6 if remote server has ipv6.
Example settings:
LOCATION /foo CALL http://www.roxen.com/
LOCATION /googletest CALL http://www.google.com/
In both these examples the Relay module tries to use the ipv6 adress provided from the DNS. This will not work, when Roxen WebServer doesn't have ipv6 set up.
A typicall error in the browser reads:
504 Gateway Timeout: Connection to remote HTTP host failedPike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7703Inheriting unfinished programs2020-03-01T15:50:14ZPeter BortasInheriting unfinished programsImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7703
Reported by Martin Karlgren <marty@roxen.com>
It's currently not possible to inherit programs that aren't finished yet. This means that you often need to do run-time...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7703
Reported by Martin Karlgren <marty@roxen.com>
It's currently not possible to inherit programs that aren't finished yet. This means that you often need to do run-time indexing rather than compile-time ("Module["Submodule"]->function()" rather than "Module.Submodule.function()"). Also, proper variable typing is not always possible (you need to declare "object var" rather than "Module.Submodule.Type var").
From src/program.c:
```
if (!(p->flags & PROGRAM_FINISHED)) {
/* Require that the inherited program really is finished in pass
* 2. Otherwise we might not have all definitions when we
* fixate our program.
*
* FIXME: Maybe this can be relaxed by registering a dependency
* and delaying compilation here?
*/
yyerror ("Cannot inherit program in pass 2 "
"which is not fully compiled yet.");
yyerror ("(You probably have a cyclic symbol dependency that the "
"compiler cannot handle.)");
}
```
Is it plausible to do what the FIXME says to overcome this limitation? Time estimate?Pike NextHenrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7644Feed Import stalled/stopped in Heap.pike2020-03-01T15:48:37ZPeter BortasFeed Import stalled/stopped in Heap.pikeImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7644
Reported by Erik Allemann <erik@roxen.com>
```
RT#26577 & RT#26578
REP 6.0.92
```
Feed Import had stopped. Debug logged repeatedly reports:
```
2d 8h 8m : Feed Im...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7644
Reported by Erik Allemann <erik@roxen.com>
```
RT#26577 & RT#26578
REP 6.0.92
```
Feed Import had stopped. Debug logged repeatedly reports:
```
2d 8h 8m : Feed Import: periodic_scan threw an error:
: Indexing the NULL value with "value".
: pike/lib/modules/ADT.pmod/Heap.pike:198: ADT.Heap()->peek()
: pike/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:1485: RoxenModule(EP/feed-import#0)->feed_monitor->monitor->check(UNDEFINED,1000,
: packages/feedimport/modules/feed-import.pike (564e550f):1508: RoxenModule(EP/feed-import#0)->feed_monitor->monitor->check(UNDEFINED,1000,@
12:09:10 : packages/feedimport/modules/feed-import.pike (564e550f):2231: RoxenModule(EP/feed-import#0)->feed_monitor->periodic_scan()
2d 8h 8m : packages/feedimport/modules/feed-import.pike (564e550f):2281: RoxenModule(EP/feed-import#0)->feed_monitor->periodic_scan_dispatch()
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7630Potential deadlock in Pike 8.0.1432020-03-01T15:48:03ZPeter BortasPotential deadlock in Pike 8.0.143Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7630
Reported by Martin Karlgren <marty@roxen.com>
My Roxen/EP (devel) process locked up. I haven't analysed the backtraces too much, but I'd expect a deadlock. Pike and ...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7630
Reported by Martin Karlgren <marty@roxen.com>
My Roxen/EP (devel) process locked up. I haven't analysed the backtraces too much, but I'd expect a deadlock. Pike and C backtraces attached.Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7578Filesystem.Monitor checks all monitors synchronously on startup2020-03-01T15:46:23ZPeter BortasFilesystem.Monitor checks all monitors synchronously on startupImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7578
Reported by Martin Karlgren <marty@roxen.com>
Filesystem.Monitor sometimes blocks the backend thread for quite a while on startup because eventstream_callback calls ...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7578
Reported by Martin Karlgren <marty@roxen.com>
Filesystem.Monitor sometimes blocks the backend thread for quite a while on startup because eventstream_callback calls check_all() synchronously.
```
: >> ### Thread 0x7fff74f56300 - Backend:
8:04:21 : >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:869: Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN/2013-03-16/page_43(E1)/pp_103729.jpg", 15, next: Wed Oct 21 08:04:21 2015, st: Stat(-rw-r--r-- 119226b))->check(UNDEFINED)
0d16h46m : >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:1352: FSGarb("/Users/marty/projects/REP-5.2-test/roxen/backup", 432000)->check_monitor(Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN/2013-03-16/page_43(E1)/pp_103729.jpg", 15, next: Wed Oct 21 08:04:21 2015, st: Stat(-rw-r--r-- 119226b)),UNDEFINED)
: >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:874: Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN/2013-03-16/page_43(E1)", 15, next: Sat Oct 17 08:04:20 2015, st: Stat(drwxr-xr-x 238b))->check(UNDEFINED)
: >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:1352: FSGarb("/Users/marty/projects/REP-5.2-test/roxen/backup", 432000)->check_monitor(Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN/2013-03-16/page_43(E1)", 15, next: Sat Oct 17 08:04:20 2015, st: Stat(drwxr-xr-x 238b)),UNDEFINED)
: >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:874: Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN/2013-03-16", 15, next: Sat Oct 17 08:04:20 2015, st: Stat(drwxr-xr-x 1768b))->check(UNDEFINED)
: >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:1352: FSGarb("/Users/marty/projects/REP-5.2-test/roxen/backup", 432000)->check_monitor(Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN/2013-03-16", 15, next: Sat Oct 17 08:04:20 2015, st: Stat(drwxr-xr-x 1768b)),UNDEFINED)
8:04:21 : >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:874: Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN", 15, next: Sat Oct 17 08:04:08 2015, st: Stat(drwxr-xr-x 3570b))->check(UNDEFINED)
0d16h46m : >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:1352: FSGarb("/Users/marty/projects/REP-5.2-test/roxen/backup", 432000)->check_monitor(Monitor("/Users/marty/projects/REP-5.2-test/roxen/backup/SN", 15, next: Sat Oct 17 08:04:08 2015, st: Stat(drwxr-xr-x 3570b)),UNDEFINED)
: >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:1379: FSGarb("/Users/marty/projects/REP-5.2-test/roxen/backup", 432000)->check_all(UNDEFINED)
: >> /Users/marty/projects/Pike/8.0/lib/modules/Filesystem.pmod/Monitor.pmod/basic.pike:764: FSGarb("/Users/marty/projects/REP-5.2-test/roxen/backup", 432000)->eventstream_callback("/Users/marty/projects/REP-5.2-test/roxen/backup/AT/2013-06-07/page_2A",1116416,7162257960850217034)
: >> -:1: Pike.Backend(0)->`()(3600.0)
: >> /Users/marty/projects/Pike/8.0/build/darwin-14.5.0-x86_64/master.pike:3619: master()._main(({"/Users/marty/projects/Pike/8.0/build/darwin-14.5.0-x86_64/pike","-DPRECOMPILED_SEARCH_MORE","-m/Users/marty/projects/Pike/8.0/build/darwin-14.5.0-x86_64/master.pike","-DMODULE_DEBUG","-DRAM_CACHE",,,11}))
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7363Compat resolver related crash.2020-03-01T15:42:02ZPeter BortasCompat resolver related crash.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7363
Reported by Martin Nilsson <nilsson@opera.com>
Create a file with
```
#pike 8.1
inherit Crypto.BlockCipher;
class _Buffer {
inherit ::this_program;
}
```
as lib/...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7363
Reported by Martin Nilsson <nilsson@opera.com>
Create a file with
```
#pike 8.1
inherit Crypto.BlockCipher;
class _Buffer {
inherit ::this_program;
}
```
as lib/8.0/modules/Crypto.pmod/CompatProxy.pmod and run hilfe, you'll get the following crash.
```
Pike v8.1 release 0 running Hilfe v3.5 (Incremental Pike Frontend)
(running in Pike 8.0 compat mode)
> Crypto.CompatProxy;
Program received signal SIGSEGV, Segmentation fault.
low_clone (p=0xd46288) at /home/nilsson/pike/src/object.c:167
167 LOW_PARENT_INFO(o,p)->parent=0;
(gdb) bt
#0 low_clone (p=0xd46288) at /home/nilsson/pike/src/object.c:167
#1 0x00000000004bc16d in parent_clone_object (p=0xd46288,
parent=parent@entry=0x8be8f0,
parent_identifier=parent_identifier@entry=19, args=args@entry=0)
at /home/nilsson/pike/src/object.c:395
#2 0x000000000042b0f4 in lower_mega_apply (args=0, o=0x8be8f0, fun=19)
at /home/nilsson/pike/src/interpret.c:2196
#3 0x000000000042d674 in mega_apply_low (args=<optimized out>,
arg1=<optimized out>, arg2=<optimized out>)
at /home/nilsson/pike/src/interpret.c:2715
#4 0x00002aaaad13e241 in init_Nettle_BufferedCipher_struct ()
at /home/nilsson/pike/src/post_modules/Nettle/cipher.cmod:1036
#5 Nettle_BufferedCipher_event_handler (ev=0)
at /home/nilsson/pike/src/post_modules/Nettle/cipher.cmod:1048
#6 0x00000000004bb9d5 in call_c_initializers (o=0x8be8f0)
at /home/nilsson/pike/src/object.c:278
#7 0x00000000004e99dd in run_pass1 (c=0xae2970)
at /home/nilsson/pike/src/program.c:9143
#8 f_compilation_compile (args=<optimized out>)
at /home/nilsson/pike/src/program.c:9669
```Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/7063The kqueue backend doesn't support out of band data.2020-03-01T15:39:35ZPeter BortasThe kqueue backend doesn't support out of band data.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7063
Reported by @grubba
The socktest.pike test "Testing out-of-band data" times out when waiting for the sent out of band data to arrive.
With OOB_DEBUG enabled on a pi...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7063
Reported by @grubba
The socktest.pike test "Testing out-of-band data" times out when waiting for the sent out of band data to arrive.
With OOB_DEBUG enabled on a pike compiled with BACKEND_DEBUG, the following is output:
```
Child: Testing out-of-band data
originator: Stdio.File("socket", "127.0.0.1:62128", 777 /* fd=9 */)
loopback: Stdio.File("socket", "127.0.0.1 62129", 777 /* fd=10 */)
[2085229328]BACKEND[0]: hook_fd_callback_box: fd 9, events 0xc, object 0x1008227d0
[2085229328]BACKEND[0]: pdb_update_fd_set(.., 9, 0, 12):
[2085229328]BACKEND[0]: fd:9 READ, ADD, [OOBAND]
[2085229328]BACKEND[0]: fd:9 WRITE, ADD
BACKEND: EV_ADD fd:9, filter:-2
BACKEND: EV_ENABLE fd:9, filter:-2
[2085229328]BACKEND[0]: hook_fd_callback_box: fd 10, events 0x4, object 0x1008227a0
[2085229328]BACKEND[0]: pdb_update_fd_set(.., 10, 0, 4):
[2085229328]BACKEND[0]: fd:10 READ, ADD, [OOBAND]
[2085229328]BACKEND[0]: Doing poll on fds:
=> 1 (timeout was: 3600)
[2085229328]BACKEND[0]: fd:9 filter:-2 flags:0x00000001 EVFILT_WRITE(146988)
[2085229328]BACKEND[0]: POLLWRBAND on 9
[2085229328]BACKEND[0]: POLLOUT on 9
[2085229328]BACKEND[0]: hooking in box for fd 9
[2085229328]BACKEND[0]: Examining box for fd 9 revents:0x000a
[2085229328]BACKEND[0]: write_oob_callback(9, 0x1008227d0)
[2085229328]BACKEND[0]: set_fd_callback_events: fd 9, events from 0xc to 0x4, object 0x1008227d0
[2085229328]BACKEND[0]: pdb_update_fd_set(.., 9, 12, 4):
[2085229328]BACKEND[0]: fd:9 WRITE, DISABLE
BACKEND: EV_DISABLE fd:9, filter:-2
S[2085229328]BACKEND[0]: set_fd_callback_events: fd 9, events from 0x4 to 0xc, object 0x1008227d0
[2085229328]BACKEND[0]: pdb_update_fd_set(.., 9, 4, 12):
[2085229328]BACKEND[0]: fd:9 WRITE, ADD
BACKEND: EV_ADD fd:9, filter:-2
BACKEND: EV_ENABLE fd:9, filter:-2
[2085229328]BACKEND[0]: set_fd_callback_events: fd 9, events from 0xc to 0x4, object 0x1008227d0
[2085229328]BACKEND[0]: pdb_update_fd_set(.., 9, 12, 4):
[2085229328]BACKEND[0]: fd:9 WRITE, DISABLE
BACKEND: EV_DISABLE fd:9, filter:-2
[2085229328]BACKEND[0]: set_fd_callback_events: fd 10, events from 0x4 to 0x4, object 0x1008227a0
[2085229328]BACKEND[0]: pdb_update_fd_set(.., 10, 4, 4):
[2085229328]BACKEND[0]: Examining box for fd -1 revents:0x0000
[2085229328]BACKEND[0]: Doing poll on fds:
[*timeout*]^C
What we can see above is that a single byte is sent on fd #9 ("S" above), but not notified on fd #10 even though it has PIKE_BIT_FD_READ_OOB (4) set.
```Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/6513Fix diagnostic decode_value2020-03-01T15:34:10ZPeter BortasFix diagnostic decode_valueImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6513
Reported by Martin Stjernholm <mast@roxen.com>
For debugging it is sometimes necessary to be able to decode data structures containing programs without a correct res...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6513
Reported by Martin Stjernholm <mast@roxen.com>
For debugging it is sometimes necessary to be able to decode data structures containing programs without a correct resolver. This is currently enabled by the ENCODE_DEBUG define in encode.c, and then passing a hidden third argument to decode_value. It should be available in normal pike builds, preferably through a separate debug_decode_value function.
This does not mean that the other debug aspects of ENCODE_DEBUG, i.e. all the stderr logging, should be available.Pike 7.6Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/6284Add utime() support for directories on WIN32.2020-03-01T15:31:06ZPeter BortasAdd utime() support for directories on WIN32.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6284
Reported by @grubba
_utime() on WIN32 doesn't support directories. From MSDN:
A return value of –1 indicates an error, in which case errno is set to one of the foll...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6284
Reported by @grubba
_utime() on WIN32 doesn't support directories. From MSDN:
A return value of –1 indicates an error, in which case errno is set to one of the following values:
EACCES
Path specifies directory or read-only file
Try to find an alternative API.
See also [bug #6220].Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/6201MinGW: Modifications needed to compile Pike 7.8.352 under MinGW2020-03-01T15:30:33ZPeter BortasMinGW: Modifications needed to compile Pike 7.8.352 under MinGWImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6201
Reported by @grubba
From the Pike mailinglist 12879:
```
From: <zenothing@hotmail.com>
Date: Thu, 2 Feb 2012 18:42:19 +0800
Subject: RE: Cannot compile pike 7.8 fro...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6201
Reported by @grubba
From the Pike mailinglist 12879:
```
From: <zenothing@hotmail.com>
Date: Thu, 2 Feb 2012 18:42:19 +0800
Subject: RE: Cannot compile pike 7.8 from git
Thanks very much.
Compile Pike-v7.8.352 under mingw successful.
following actions are needed:
* replace PIDLIST_ABSOLUTE with ITEMIDLIST* in module system/nt.c
* remove line __declspec(dllimport) void __cdecl _dosmaperr(unsigned long);
in src/fdlib.c
* insert line #define STRUNCATE 80 into src/fdlib.c
* use this cmdline to make: CONFIGUREARGS="--without-COM
--without-machine-code" make
```
Guo XuesongPike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/6155Mysql.mysql.set_charset does not trig error when connected to old mysql server2020-03-01T15:29:28ZPeter BortasMysql.mysql.set_charset does not trig error when connected to old mysql serverImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6155
Reported by Martin Stjernholm <mast@roxen.com>
When connected to an old mysql server without charset support, Mysql.mysql.set_charset does not throw an error as it s...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6155
Reported by Martin Stjernholm <mast@roxen.com>
When connected to an old mysql server without charset support, Mysql.mysql.set_charset does not throw an error as it should. Instead the error occurs in the query afterwards, where it often won't be caught properly:
```
Pike v7.8 release 613 running Hilfe v3.5 (Incremental Pike Frontend)
> object o=Sql.Sql ("mysql://rw@megalon.roxen.com:4852/autodoc");
> o->set_charset("unicode");
(1) Result: 0
> o->query ("select 'apa'");
big_query(): Query "SET character_set_client=latin1" failed (Unknown system variable 'character_set_client')
/home/mast/Pike/stable/build/linux-x86_64/lib/modules/Mysql.so:1: mysql(/*megalon.roxen.com via TCP/IP*/)->big_query("SET character_set_client=latin1")
/home/mast/Pike/stable/lib/modules/Sql.pmod/mysql.pike:778: mysql(/*megalon.roxen.com via TCP/IP*/)->big_query("select 'apa'",UNDEFINED,UNDEFINED)
/home/mast/Pike/stable/lib/modules/Sql.pmod/Sql.pike:648: Sql.mysql(/*megalon.roxen.com via TCP/IP*/)->query("select 'apa'")
```
This only occurs when pike has been compiled with a mysql client lib new enough to contain mysql_set_character_set, so the problem is that that function doesn't trig an error. The doc isn't clear, but it can arguably be interpreted that an error should occur:
This function works like the SET NAMES statement, but
also sets the value of mysql->charset, and thus affects
the character set used by mysql_real_escape_string()
Return Values
Zero for success. Nonzero if an error occurred.
The db server in question does not support SET NAMES.Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/6153Suspected race in forkd2020-03-01T15:29:13ZPeter BortasSuspected race in forkdImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6153
Reported by Martin Stjernholm <mast@roxen.com>
Running the roxen testsuite, pike sometimes get stuck in a busyloop:
```
>> /home/mast/Pike/stable/lib/modules/Proces...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6153
Reported by Martin Stjernholm <mast@roxen.com>
Running the roxen testsuite, pike sometimes get stuck in a busyloop:
```
>> /home/mast/Pike/stable/lib/modules/Process.pmod:336: Process.Process()->do_poll(3600.0)
>> /home/mast/Pike/stable/lib/modules/Process.pmod:372: Process.Process()->wait()
>> modules/sitebuilder/pike-modules/VC.pmod/CVS.pmod/CVS.pike (rev 1.51):163: VC.CVS.CVS()->command2(0,({"/home/mast/Roxen/5.2/server/modules/sitebuilder/bin/cvs","-!","-f","-q","-d:local:/home/mast/Roxen/5.2/var/test_repository/Test_Platform.sb/cvsroot","add","-kb","__info"}),0)
>> modules/sitebuilder/pike-modules/VC.pmod/CVS.pmod/file.pike (rev 1.108):452: VC.CVS.file()->add(UNDEFINED)
/.../
```
It looks like the busyloop is the while block in Process.Process.wait. forkd is enabled and the forkd process did not have the cvs process running anymore.
The hang is not reliably reproducible, but I get it approximately once every fourth testsuite run.
This is with a git fresh pike 7.8.613.Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/6092forkd: Failed to write spawn request2020-03-01T15:26:05ZPeter Bortasforkd: Failed to write spawn requestImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6092
Reported by Jonas Wallden <jonasw@roxen.com>
Seen on macos_x86_64:
```
: Failed to write spawn request (-1 != 434).
12:52:27 : Error in VCDir(0:0:[FOO]::...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=6092
Reported by Jonas Wallden <jonasw@roxen.com>
Seen on macos_x86_64:
```
: Failed to write spawn request (-1 != 434).
12:52:27 : Error in VCDir(0:0:[FOO]::/global/data/mf/items/3820)->update_state. Additional info:
8m 7.7s : _statcache = Stat(drwxr-xr-x 204b)
: _state = 0
: _md = 0
: status = 0
: infostat = Stat(-rw-r--r-- 89b)
12:52:27 : pike/lib/modules/Process.pmod:230: Process.Process()->create(({"/scratch/FOO/roxen/server-5.2.40/modules/sitebuilder/bin/cvs","-!","-f","-q","-d:local:/scratch/FOO/FOO.sb/cvsroot","-n","status","-v","__info"}),mapping[5])
8m 7.7s : pike/lib/modules/Process.pmod:112: Process->Process()
: modules/sitebuilder/pike-modules/VC.pmod/CVS.pmod/CVS.pike (rev 1.51):129: /scratch/FOO/roxen/server-5.2.40/modules/sitebuilder/pike-modules/VC.pmod/CVS.pmod/CVS()->command2(0,@0=({"/scratch/FOO/roxen/server-5.2.40/modules/sitebuilder/bin/cvs","-!","-f","-q","-d:local:/scratch/FOO/FOO.sb/cvsroot","-n","status","-v","__info"}),0)
```
(Customer name censored.)Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/5466XML parser doesn't flag errors for <?xml ...?> in wrong places2020-03-01T15:18:36ZPeter BortasXML parser doesn't flag errors for <?xml ...?> in wrong placesImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5466
Reported by Jonas Wallden <jonasw@roxen.com>
When the XML parser encounters a <?xml ...?> directive in unexpected places (i.e. not at the very beginning of the docum...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5466
Reported by Jonas Wallden <jonasw@roxen.com>
When the XML parser encounters a <?xml ...?> directive in unexpected places (i.e. not at the very beginning of the document modulo BOM) it is handled incorrectly:
- It is accepted in violiation of the spec (§2.6, <http://www.w3.org/TR/REC-xml/#sec-pi>).
- The comment in compat_allow_errors() says Pike treats it as a normal PI when using the strictest setting.
- The parser callback is invoked with the "<?xml" type and not the "<?" type, thus flagging is as a real XML header and failing in the misguided intention to identify it as a PI.Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/4934pango items are listed as separate functions2020-03-01T15:13:13ZPeter Bortaspango items are listed as separate functionsImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4934
Reference: http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/GTK2/Pango.AttrList.html
Reported by yvan vander sanden <yvan@youngmusic.org>
On the pike ...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4934
Reference: http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/GTK2/Pango.AttrList.html
Reported by yvan vander sanden <yvan@youngmusic.org>
On the pike website (module reference), pango functions are listed as GTK2.Pango.Function.
Example: GTK2.Pango.FontDescription()
in the GTK2 test files that come with the source it's:
```
object font_desc= Pango.FontDescription("monospace 10");
```
(which could be right if GTK2 is imported, but that's not the case)
But both are wrong, since it's actually:
GTK2.PangoFontDescription()
Same goes for all other pango functions/objects/programs. It might be a timesaver for new users like me to have the correct information on this on all places :-)
regards,
yvan vander sandenPike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbström