pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2009-04-16T14:11:39Zhttps://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/1013array_sscanf("hej","%s%n") cores2009-04-16T14:11:39ZPeter Bortasarray_sscanf("hej","%s%n") coresImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1013
Reported by Mirar , Idonex Heavy Industries <mirar@roxen.com>
```
| tsunami% pike
| Pike v7.1 release 17 running Hilfe v2.0 (Incremental Pike Frontend)
| > array_s...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1013
Reported by Mirar , Idonex Heavy Industries <mirar@roxen.com>
```
| tsunami% pike
| Pike v7.1 release 17 running Hilfe v2.0 (Incremental Pike Frontend)
| > array_sscanf("hej","%s%n");
| zsh: segmentation fault pike
(gdb) run
Starting program: /usr/local/bin/pike
Pike v7.1 release 17 running Hilfe v2.0 (Incremental Pike Frontend)
> array_sscanf("hej","%s%n");
Program received signal SIGSEGV, Segmentation fault.
0x80fd59d in low_do_hash (s=0x8307a48, len__=-137394757, size_shift=0)
at /users/mirar/pike/src/stralloc.c:54
54 DO_HASHMEM(full_hash_value, s, len__<<size_shift,
HASH_PREFIX<<size_shift);
(gdb) bt
#0 0x80fd59d in low_do_hash (s=0x8307a48, len__=-137394757, size_shift=0)
at /users/mirar/pike/src/stralloc.c:54
#1 0x80feab4 in debug_make_shared_binary_string (str=0x8307a48 "hej",
len=4157572539) at /users/mirar/pike/src/stralloc.c:670
#2 0x80feb9c in debug_make_shared_binary_string0 (str=0x8307a48 "hej",
len=4157572539) at /users/mirar/pike/src/stralloc.c:709
#3 0x80dd83c in very_low_sscanf_0_0 (input=0x8307a48 "hej", input_len=3,
match=0x8307b10 "%s%n", match_len=4, chars_matched=0xbfffdde4,
success=0xbfffdde8) at /users/mirar/pike/src/opcodes.c:1568
#4 0x80e7422 in f_sscanf (args=2) at /users/mirar/pike/src/opcodes.c:1740
#5 0x807cfa3 in mega_apply (type=APPLY_SVALUE, args=2, arg1=0x8313018,
arg2=0x0) at /users/mirar/pike/src/interpret.c:971
#6 0x807bda1 in eval_instruction_without_debug (pc=0x82ea584 "#")
at /users/mirar/pike/src/interpret_functions.h:1447
#7 0x807e556 in apply_low_safe_and_stupid (o=0x82a9c84, offset=5)
at /users/mirar/pike/src/interpret.c:775
#8 0x811d49b in eval_low (n=0x83190ac) at /users/mirar/pike/src/las.c:4501
#9 0x811d8c6 in eval (n=0x83190ac) at /users/mirar/pike/src/las.c:4576
#10 0x8115705 in optimize (n=0x8318fec) at /users/mirar/pike/src/las.c:4319
#11 0x810e375 in debug_mknode (token=291, a=0x8318f8c, b=0x0)
at /users/mirar/pike/src/las.c:1029
#12 0x806162b in yyparse () at language.yacc:3213
#13 0x80fac2e in compile (prog=0x82e9650, handler=0x0, major=-1, minor=-1)
at /users/mirar/pike/src/program.c:3416
#14 0x8125a99 in f_compile (args=4)
at /users/mirar/pike/src/builtin_functions.c:2544
#15 0x807cfa3 in mega_apply (type=APPLY_SVALUE, args=4, arg1=0x82ced04,
arg2=0x0) at /users/mirar/pike/src/interpret.c:971
#16 0x8076b95 in eval_instruction_without_debug (
pc=0x82cd62a "xi\004>\n\017\006>\tH\006\017\006\032\004\005")
at /users/mirar/pike/src/interpret_functions.h:621
#17 0x807df89 in o_catch (
pc=0x82cd625
"G\001f\a\005xi\004>\n\017\006>\tH\006\017\006\032\004\005")
at /users/mirar/pike/src/interpret.c:775
#18 0x807897c in eval_instruction_without_debug (pc=0x82cd621 "\n")
at /users/mirar/pike/src/interpret_functions.h:852
#19 0x807da1f in mega_apply (type=APPLY_LOW, args=1, arg1=0x82a9fe4,
arg2=0x8)
at /users/mirar/pike/src/interpret.c:775
#20 0x807bda1 in eval_instruction_without_debug (pc=0x82cd683 "d\002u·")
at /users/mirar/pike/src/interpret_functions.h:1447
#21 0x807da1f in mega_apply (type=APPLY_LOW, args=2, arg1=0x82a9fe4,
arg2=0xc)
at /users/mirar/pike/src/interpret.c:775
#22 0x807b929 in eval_instruction_without_debug (
pc=0x82ce01a "%\n\001R\002R\006G")
at /users/mirar/pike/src/interpret_functions.h:1420
#23 0x807da1f in mega_apply (type=APPLY_LOW, args=1, arg1=0x82a9fe4,
arg2=0x21)
at /users/mirar/pike/src/interpret.c:775
#24 0x807bda1 in eval_instruction_without_debug (pc=0x82cdc1b "d")
at /users/mirar/pike/src/interpret_functions.h:1447
#25 0x807da1f in mega_apply (type=APPLY_LOW, args=0, arg1=0x82a9fe4,
arg2=0x1e)
at /users/mirar/pike/src/interpret.c:775
#26 0x807bda1 in eval_instruction_without_debug (
pc=0x82cd8e2 "]\roD\r\237\016h$\003\001S\002D\r\234i\001]\roD\rI")
at /users/mirar/pike/src/interpret_functions.h:1447
#27 0x807da1f in mega_apply (type=APPLY_LOW, args=1, arg1=0x82a9fe4,
arg2=0x1b)
at /users/mirar/pike/src/interpret.c:775
#28 0x807b929 in eval_instruction_without_debug (pc=0x82ce04b "$")
at /users/mirar/pike/src/interpret_functions.h:1420
#29 0x807da1f in mega_apply (type=APPLY_LOW, args=1, arg1=0x82a9fe4,
arg2=0x22)
at /users/mirar/pike/src/interpret.c:775
#30 0x807b929 in eval_instruction_without_debug (
pc=0x82d94c4
"oD%\223\017D\r\234uÙÿÿÿ?\020sÔÿÿÿo\237&oD%\017\noD\a?\0224$")
at /users/mirar/pike/src/interpret_functions.h:1420
#31 0x807da1f in mega_apply (type=APPLY_LOW, args=0, arg1=0x82a9fe4,
arg2=0x23)
at /users/mirar/pike/src/interpret.c:775
#32 0x807eae4 in apply_lfun (o=0x82a9fe4, fun=1, args=0)
at /users/mirar/pike/src/interpret.c:1565
#33 0x80d6093 in call_pike_initializers (o=0x82a9fe4, args=0)
at /users/mirar/pike/src/object.c:255
#34 0x80d64b7 in parent_clone_object (p=0x82d92b8, parent=0x82a9f84,
parent_identifier=1, args=0) at /users/mirar/pike/src/object.c:310
#35 0x807d6b5 in mega_apply (type=APPLY_STACK, args=0, arg1=0x0, arg2=0x0)
at /users/mirar/pike/src/interpret.c:1216
#36 0x807bda1 in eval_instruction_without_debug (pc=0x82d01ec
"o7\020(s\013")
at /users/mirar/pike/src/interpret_functions.h:1447
#37 0x807da1f in mega_apply (type=APPLY_LOW, args=2, arg1=0x82aa164,
arg2=0x49)
at /users/mirar/pike/src/interpret.c:775
#38 0x807eb3e in apply (o=0x82aa164, fun=0x8199907 "_main", args=2)
at /users/mirar/pike/src/interpret.c:1577
#39 0x80cdbdd in main (argc=1, argv=0xbffffcdc)
at /users/mirar/pike/src/main.c:560
```Pike 7.2Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/4649BACKPORT: sendfile truncation issue (Was: Files exceeding proto cache size ar...2009-04-16T14:11:39ZPeter BortasBACKPORT: sendfile truncation issue (Was: Files exceeding proto cache size are corrupted)Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4649
Reported by Jonas Wallden <jonasw@roxen.com>
Requesting a file whose size is bigger than the protocol cache threshold will not be sent completely.
Both Safari and Fi...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=4649
Reported by Jonas Wallden <jonasw@roxen.com>
Requesting a file whose size is bigger than the protocol cache threshold will not be sent completely.
Both Safari and Firefox will stall and later give up with bytes missing at the end of the file (a few
hundred missing bytes is the normal case).
The same test works fine in 4.5.Pike 7.8Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://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/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/7616Broken error recovery in parser.2016-01-07T12:53:53ZPeter BortasBroken error recovery in parser.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7616
Reported by @grubba
From [LysLysKOM 21578942]:
```
21578942 idag 01:55 /28 rader/ Chris Angelico <rosuav@gmail.com>
Sänt av: SRS0+PiTo=NE=lists.lysator.liu.se=pike...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=7616
Reported by @grubba
From [LysLysKOM 21578942]:
```
21578942 idag 01:55 /28 rader/ Chris Angelico <rosuav@gmail.com>
Sänt av: SRS0+PiTo=NE=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: idag 01:55 av Brevbäraren
Extern mottagare: pike-devel@lists.lysator.liu.se <pike-devel@lists.lysator.liu.se>
Mottagare: Pike (-) developers forum <19557>
Ärende: Internal compiler error (push_compiler_frame0)
------------------------------------------------------------
The following code triggers an "internal error" (seems to be from
language.yacc:699).
function frame0(function x)
{
return lambda()
{
if (string bad=x() //Missing close parenthesis
{
}
};
}
$ pike frame0.pike
frame0.pike:6:Internal compiler error (push_compiler_frame0).
frame0.pike:8:Missing ')'.
frame0.pike:10:Missing ';'.
frame0.pike:10:Unexpected end of file.
frame0.pike:10:Missing '}'.
frame0.pike:10:Opening '{' was here.
frame0.pike:10:Unexpected end of file.
Pike: Failed to compile script.
```
The code *is* in error (there should be another close parenthesis on
line 5), but the actual error is masked. Is this worth looking into?
ChrisA
(21578942) /Chris Angelico <rosuav@gmail.com>/------Pike 8.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/2830Bug in credentials handling.2009-04-16T14:11:39ZPeter BortasBug in credentials handling.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2830
Reported by @grubba
$ cat bug.cred.pike
class User{}
```
object luser = User();
int main(int argc, array(string) argv)
{
object luser_creds = Pike.Security.Creds...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2830
Reported by @grubba
$ cat bug.cred.pike
class User{}
```
object luser = User();
int main(int argc, array(string) argv)
{
object luser_creds = Pike.Security.Creds(luser, 0, 0);
mixed result = call_with_creds(luser_creds, Stdio.File, "/dev/null");
return 0;
}
$ ./pike -mmaster.pike bug.cred.pike
Segmentation Fault (core dumped)
```Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/2821Calendar.ISO.datetime() weirdness...2009-04-16T14:11:39ZPeter BortasCalendar.ISO.datetime() weirdness...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2821
Reported by Xavier Beaudouin, ISDnet <kiwi@isdnet.net>
Calendar.ISO.datetime ((int)random (10000000))->weekday; on pike 7.2 (even
7.0) give some strange results.
``...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=2821
Reported by Xavier Beaudouin, ISDnet <kiwi@isdnet.net>
Calendar.ISO.datetime ((int)random (10000000))->weekday; on pike 7.2 (even
7.0) give some strange results.
```
On FreeBSD and Solaris we have :
Pike v7.2 release 276 running Hilfe v2.0 (Incremental Pike Frontend)
> Calendar.ISO.datetime ((int)random (10000000))->weekday;
Result: 0
> Calendar.ISO.datetime ((int)random (5))->weekday;
Result: 0
```
On Linux (debian woody, pike 7.0.361 the result is allway 3....Pike 7.2Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/1181Can't build Pike 7.2 or 7.3 in separate build directory2009-04-16T14:11:39ZPeter BortasCan't build Pike 7.2 or 7.3 in separate build directoryImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1181
Reported by David Hedbor, Idonex / Real Networks <david@hedbor.org>
I can no longer build Pike 7.2 or 7.3 using a separate build directory. The
object files gets pla...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=1181
Reported by David Hedbor, Idonex / Real Networks <david@hedbor.org>
I can no longer build Pike 7.2 or 7.3 using a separate build directory. The
object files gets placed in the source tree for some weird reason. Pike 7.0
build works fine so it's nothing wrong on my end AFAIK. I tried checking
out Pike 7.2 from scratch (removing the old source tree) and then running
'make' (i.e the "automatic build" feature). It didn't work. This is an
example of some output when running make -n (notice the last line - ie the
.o file destination):
```
echo Making Gdbm; \
( cd Gdbm && \
( rm remake >/dev/null 2>&1 || : ) && \
( make MODNAME=Gdbm || \
( test -f remake && make MODNAME=Gdbm ) ) \
) || exit $?;
Making Gdbm
make[3]: Entering directory
`/home/neotron/pike/7.2/build/linux-2.4.1-4mdk-i686/modules/Gdbm'
if test "x" != x ; then echo "LINKER_OPTIONS+=" ; else : ; fi ; echo ""
>linker_options
echo "" >modlist_headers
echo "" >modlist_segment
echo "Compiling /home/neotron/pike/7.2/src/modules/Gdbm/gdbmmod.c" ;\
if /home/neotron/pike/7.2/build/linux-2.4.1-4mdk-i686/smartlink gcc -I.
-I/home/neotron/pike/7.2/src/modules/Gdbm
-I/home/neotron/pike/7.2/src/modules/Gdbm/../.. -I../.. -I.
-I/usr/local/include -I/usr/X11R6-DRI/include -I/usr/X11R6/include
-I/home/neotron/pike/7.2/src
-I/home/neotron/pike/7.2/build/linux-2.4.1-4mdk-i686 -g -mpentiumpro -O2
-pipe -W -Wall -Wno-unused -Wcomment -Wformat
-Wimplicit-function-declaration -Wmultichar -Wswitch -Wuninitialized
-Wpointer-arith -Wchar-subscripts -Wno-long-long -fPIC -DDYNAMIC_MODULE
-c /home/neotron/pike/7.2/src/modules/Gdbm/gdbmmod.c -o
/home/neotron/pike/7.2/src/modules/Gdbm/gdbmmod.o ; then : ;\
```Pike 7.2https://git.lysator.liu.se/pikelang/pike/-/issues/8002Can't build Pike 8.0 in Distmaker [bug 7827]2017-09-15T14:40:31ZPeter BortasCan't build Pike 8.0 in Distmaker [bug 7827]Imported from https://youtrack.roxen.com/issue/PIKE-2
Reported by @grubba
From Bugzilla [bug #7827]:
Getting this on RHEL7_x86_64:
```
Linking VCDiff
vcdiff_wrapper.o: In function `__static_initialization_and_destruction_0':
/usr/incl...Imported from https://youtrack.roxen.com/issue/PIKE-2
Reported by @grubba
From Bugzilla [bug #7827]:
Getting this on RHEL7_x86_64:
```
Linking VCDiff
vcdiff_wrapper.o: In function `__static_initialization_and_destruction_0':
/usr/include/c++/4.8.2/iostream:74: undefined reference to `__dso_handle'
/usr/bin/ld: vcdiff_wrapper.o: relocation R_X86_64_PC32 against undefined
hidden symbol `__dso_handle' can not be used when making a shared object
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Linking failed:
```
I think Pike/8.0: c65cf769826f726 could be the cause. It claims to improve
FreeBSD linking, but also adds "-nostartfiles" to Linux builds (and possibly
other OSes). Is that the idea?https://git.lysator.liu.se/pikelang/pike/-/issues/10029CID 1461176: Null pointer dereferences (FORWARD_NULL)2020-04-05T12:44:28ZHenrik (Grubba) GrubbströmCID 1461176: Null pointer dereferences (FORWARD_NULL)```
/home/covbuilder/pike/Pike-v8.1-snapshot/src/docode.c: 3033 in do_code_block()
________________________________________________________________________________________________________
*** CID 1461176: Null pointer dereferences (FOR...```
/home/covbuilder/pike/Pike-v8.1-snapshot/src/docode.c: 3033 in do_code_block()
________________________________________________________________________________________________________
*** CID 1461176: Null pointer dereferences (FORWARD_NULL)
/home/covbuilder/pike/Pike-v8.1-snapshot/src/docode.c: 3033 in do_code_block()
3027
3028 init_bytecode();
3029 label_no=1;
3030 PUSH_STATEMENT_LABEL;
3031 save_label = current_label->prev;
3032 current_label->prev = NULL;
>>> CID 1461176: Null pointer dereferences (FORWARD_NULL)
>>> Dereferencing null pointer "current_label->prev".
3033 PUSH_CLEANUP_FRAME(NULL, NULL);
3034 current_stack_depth = 0;
3035
3036 /* NOTE: This is no ordinary label... */
3037 low_insert_label(0);
3038 emit0(F_ENTRY);
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/10028CID 1461177: Null pointer dereferences (FORWARD_NULL)2020-04-05T12:44:28ZHenrik (Grubba) GrubbströmCID 1461177: Null pointer dereferences (FORWARD_NULL)```
/home/covbuilder/pike/Pike-v8.1-snapshot/src/docode.c: 3274 in docode()
________________________________________________________________________________________________________
*** CID 1461177: Null pointer dereferences (FORWARD_NU...```
/home/covbuilder/pike/Pike-v8.1-snapshot/src/docode.c: 3274 in docode()
________________________________________________________________________________________________________
*** CID 1461177: Null pointer dereferences (FORWARD_NULL)
/home/covbuilder/pike/Pike-v8.1-snapshot/src/docode.c: 3274 in docode()
3268 struct byte_buffer instrbuf_save = instrbuf;
3269 struct statement_label *label_save;
3270
3271 PUSH_STATEMENT_LABEL;
3272 label_save = current_label->prev;
3273 current_label->prev = NULL;
>>> CID 1461177: Null pointer dereferences (FORWARD_NULL)
>>> Dereferencing null pointer "current_label->prev".
3274 PUSH_CLEANUP_FRAME(NULL, NULL);
3275 label_no=1;
3276 current_stack_depth = 0;
3277 Pike_compiler->compiler_frame->generator_local = -1;
3278 init_bytecode();
3279
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/734CLOB and BLOB support missing in the Oracle module.2009-04-16T14:11:39ZPeter BortasCLOB and BLOB support missing in the Oracle module.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=734
Reported by Stefan Wallström <stewa@lysator.liu.se>
CLOB and BLOB support missing in the Oracle module.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=734
Reported by Stefan Wallström <stewa@lysator.liu.se>
CLOB and BLOB support missing in the Oracle module.Pike 7.0Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10097Compiler C Stack overflow in type checker.2022-10-17T13:35:20ZHenrik (Grubba) GrubbströmCompiler C Stack overflow in type checker.LysLysKOM 25574453:
```
25574453 2022-10-16 10:01 /14 rader/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Mottagare: Henrik Grubbström (Lysator) <17112>
Mottagare: Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) <17998>
Mottaget: 2022-10-16...LysLysKOM 25574453:
```
25574453 2022-10-16 10:01 /14 rader/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Mottagare: Henrik Grubbström (Lysator) <17112>
Mottagare: Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) <17998>
Mottaget: 2022-10-16 10:01
Ärende: C stack overflow
------------------------------------------------------------
Jag försökte minimera ett fall för att reproducera den C stack
overflow som är i testsuite nu. Jag kom fram till följande:
Pike v8.1 release 18 running Hilfe v3.5 (Incremental Pike Frontend)
> compile_string("void a() { foreach(({`/, `^});; function op); }");
C stack overflow.
-:1: PikeCompiler("", -1, -1, UNDEFINED, UNDEFINED)->compile()
master.pike:1088:
DefaultCompilerEnvironment->compile("void a() { foreach(({`/, `^});; function op); }",UNDEFINED,-1,-1,UNDEFINED,UNDEFINED)
master.pike:1102:
compile("void a() { foreach(({`/, `^});; function op); }",UNDEFINED,-1,-1,UNDEFINED,UNDEFINED)
master.pike:1183:
compile_string("void a() { foreach(({`/, `^});; function op); }","-",UNDEFINED,UNDEFINED,UNDEFINED,UNDEFINED)
>
(25574453) /Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)/
Kommentar i text 25574467 av Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
```
```
25574467 2022-10-16 10:26 /26 rader/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Kommentar till text 25574453 av Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Mottagare: Henrik Grubbström (Lysator) <17113>
Mottagare: Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) <17999>
Ärende: C stack overflow
------------------------------------------------------------
BTW, om man försöker detta direkt i Hilfe så döljs felen:
Pike v8.1 release 18 running Hilfe v3.5 (Incremental Pike Frontend)
> foreach(({`/, `^});; function op) write("%O\n", op);
> void a() { foreach(({`/, `^});; function op); }
> a();
Compiler Error: 1: Undefined identifier a.
Compiler Error: 1: Calling a void expression.
>
Notera att det inte blev någon utskrift och att "a" inte blev
definierad. I 8.0:
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> foreach(({`/, `^});; function op) write("%O\n", op);
`/
`^
Ok.
> void a() { foreach(({`/, `^});; function op); }
> a();
Compiler Warning: 1: Returning a void expression. Converted to zero.
(1) Result: 0
>
Känns som att det kanske hade varit trevligt att få någon indikation
på att något gick fel?
(25574467) /Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)/
```Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/3022constant using another constant value dumps core.2009-04-16T14:11:39ZPeter Bortasconstant using another constant value dumps core.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3022
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
```
constant B = 0;
class A {
constant C = B;
}
int main() {}
```
Starting program: /home/nilsson/Pike/7...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3022
Reported by Martin Nilsson, IDA <nilsson@pike.ida.liu.se>
```
constant B = 0;
class A {
constant C = B;
}
int main() {}
```
Starting program: /home/nilsson/Pike/7.3/build/linux-2.4.2-2-i586/pike
'-m/home/nilsson/Pike/7.3/build/linux-2.4.2-2-i586/master.pike' 'test.pike'
[New Thread 1024 (LWP 8101)]
```
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 8101)]
0x080691f3 in find_external_context (loc=0xbfffeae8, arg2=1)
at /home/nilsson/Pike/7.3/src/interpret.c:527
527 switch(loc->inherit->parent_offset)
(gdb) bt
#0 0x080691f3 in find_external_context (loc=0xbfffeae8, arg2=1)
at /home/nilsson/Pike/7.3/src/interpret.c:527
#1 0x08069b7c in opcode_F_EXTERNAL (arg1=0, arg2=1)
at /home/nilsson/Pike/7.3/src/interpret_functions.h:312
#2 0x082eef0b in ?? ()
#3 0x08072c0c in apply_low_safe_and_stupid (o=0x82eeed0, offset=0)
at /home/nilsson/Pike/7.3/src/interpret.c:1517
#4 0x0811677c in eval_low (n=0x82e99dc)
at /home/nilsson/Pike/7.3/src/las.c:5195
#5 0x08061214 in yyparse () at language.yacc:532
#6 0x080ed325 in run_pass1 (c=0x82ee640)
at /home/nilsson/Pike/7.3/src/program.c:5064
#7 0x080ed93b in compile (aprog=0x82ee520, ahandler=0x0, amajor=-1,
aminor=-1, atarget=0x829d9ac, aplaceholder=0x0)
at /home/nilsson/Pike/7.3/src/program.c:5325
#8 0x0811dfe1 in f_compile (args=6)
at /home/nilsson/Pike/7.3/src/builtin_functions.c:3154
#9 0x08070108 in opcode_F_CALL_BUILTIN (arg1=11)
at /home/nilsson/Pike/7.3/src/interpret_functions.h:2036
#10 0x083275e8 in ?? ()
#11 0x0807291b in o_catch (
pc=0x8328588
"¡@=!\b\213\025H=!\b\211\002\203Â\004\211\025H=!\b\213\025P=!\b\213R
\201Â0") at /home/nilsson/Pike/7.3/src/interpret.c:1440
#12 0x0806d1b2 in opcode_F_CATCH ()
at /home/nilsson/Pike/7.3/src/interpret_functions.h:1139
#13 0x08328584 in ?? ()
#14 0x08072840 in mega_apply (type=APPLY_LOW, args=2, arg1=0x82c49a0,
arg2=0x21) at /home/nilsson/Pike/7.3/src/interpret.c:1402
#15 0x080d2220 in o_cast (type=0x829b1e4, run_time_type=5)
at /home/nilsson/Pike/7.3/src/opcodes.c:558
#16 0x080d2e9b in f_cast () at /home/nilsson/Pike/7.3/src/opcodes.c:794
#17 0x0832e352 in ?? ()
#18 0x0807291b in o_catch (pc=0x832e2ff "Ç\004$A")
at /home/nilsson/Pike/7.3/src/interpret.c:1440
#19 0x0806d1b2 in opcode_F_CATCH ()
at /home/nilsson/Pike/7.3/src/interpret_functions.h:1139
#20 0x0832e2fb in ?? ()
#21 0x08072840 in mega_apply (type=APPLY_LOW, args=2, arg1=0x82c49a0,
arg2=0x51) at /home/nilsson/Pike/7.3/src/interpret.c:1402
#22 0x08073327 in apply (o=0x82c49a0, fun=0x819bd37 "_main", args=2)
at /home/nilsson/Pike/7.3/src/interpret.c:1703
#23 0x080c6d61 in main (argc=3, argv=0xbffffaac)
at /home/nilsson/Pike/7.3/src/main.c:716
#24 0x400c7316 in __libc_start_main (main=0x80c63d0 <main>, argc=3,
ubp_av=0xbffffaac, init=0x805f984 <_init>, fini=0x817bfa0 <_fini>,
rtld_fini=0x4000d2fc <_dl_fini>, stack_end=0xbffffa9c)
at ../sysdeps/generic/libc-start.c:129
```Pike 7.6Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/5509Core dump in really_free_array2010-08-17T16:13:35ZPeter BortasCore dump in really_free_arrayImported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5509
Reported by Marcus Wellhardh <wellhard@roxen.com>
Roxen crashed and restarted with this error (roxen-4.5.410-release-ep-macosx_x86.sh)
```
Exception Type: EXC_...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=5509
Reported by Marcus Wellhardh <wellhard@roxen.com>
Roxen crashed and restarted with this error (roxen-4.5.410-release-ep-macosx_x86.sh)
```
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000000c1f0cd87
Crashed Thread: 0
Thread 0 Crashed:
0 0x0003ec9b really_free_array + 59 (array.c:125)
1 0x00047642 backend_do_call_outs + 290 (backend.cmod:1970)
2 0x00048581 low_backend_once + 993 (backend.cmod:1444)
3 0x00048a60 f_Backend_cq__backtick_28_29 + 112 (backend.cmod:1484)
4 0x00015855 low_mega_apply + 3109 (apply_low.h:195)
5 0x000178a2 opcode_F_APPLY_AND_POP + 98 (interpret_functions.h:1878)
6 0x010b37cb 0 + 17512395
7 0x00017ee8 o_catch + 232 (interpret.c:1831)
8 0x00017f9d opcode_F_CATCH + 61 (interpret_functions.h:1195)
9 0x010b377d 0 + 17512317
10 0x00016235 mega_apply + 101 (interpret.c:1787)
11 0x00018bf7 apply + 55 (interpret.c:2095)
12 0x00083f93 main + 2579 (main.c:757)
13 0x00001eb2 _start + 216
14 0x00001dd9 start + 41
```Pike 7.4Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10089Coredump with new array type2022-09-02T08:47:56ZMartin NilssonCoredump with new array type```Pike v8.1 release 18 running Hilfe v3.5 (Incremental Pike Frontend)
> array(3) foo;
Program received signal SIGSEGV, Segmentation fault.
0x000055555562457d in debug_push_int_type (min=min@entry=-2147483648,
max=max@entry=21474836...```Pike v8.1 release 18 running Hilfe v3.5 (Incremental Pike Frontend)
> array(3) foo;
Program received signal SIGSEGV, Segmentation fault.
0x000055555562457d in debug_push_int_type (min=min@entry=-2147483648,
max=max@entry=2147483647) at /home/nilsson/pike/src/pike_types.cmod:843
843 *(++Pike_compiler->type_stackp) = mk_type(T_INT,
(gdb) bt
#0 0x000055555562457d in debug_push_int_type (min=min@entry=-2147483648,
max=max@entry=2147483647) at /home/nilsson/pike/src/pike_types.cmod:843
#1 0x0000555555596671 in yyparse () at language.yacc:1707
#2 0x000055555566e920 in do_yyparse ()
at /home/nilsson/pike/src/pike_compiler.cmod:370
#3 0x0000555555672be5 in run_pass1 (c=0x555555b33ed0)
at /home/nilsson/pike/src/pike_compiler.cmod:1160
#4 f_compilation_compile (args=<optimized out>)
at /home/nilsson/pike/src/pike_compiler.cmod:1774
#5 0x00005555555a97fe in lower_mega_apply (args=args@entry=0,
o=o@entry=0x555555a5ecf8, fun=1) at /home/nilsson/pike/src/interpret.c:2586
#6 0x00005555555aa2a2 in jump_opcode_F_CALL_OTHER (arg1=13)
at /home/nilsson/pike/src/interpret_functions.h:2428
```Pike 9.0Henrik (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/10074Crypto.AES.CCM produces incorrect results2021-12-09T09:35:17ZJoshua RogersCrypto.AES.CCM produces incorrect resultsHi there,
While performing some unit tests with Pike's Crypto.AES.CCM, I've run into an issue of the digest function producing "incorrect" results.
During my tests, I'm using two unit tests.
The first test is:
```
key: 1a44f3550688fddb...Hi there,
While performing some unit tests with Pike's Crypto.AES.CCM, I've run into an issue of the digest function producing "incorrect" results.
During my tests, I'm using two unit tests.
The first test is:
```
key: 1a44f3550688fddbc1e5041dc98952c0
iv: 5d2904298f668ba95eaa1797
aad: d55908958b70abee81054cdf3d3df5
msg:
expected digest: 5c71b4f069cfa13b7634db4b13e7be7d
```
And the second test is:
```
key: 439fd5c3b76587d5a601ba6ef8fad214
iv: ed1d316d0834d174c1b5b438
aad: eae252f42d2c71
msg:
expected digest: e8530426cbabf63633ff373159247e38
```
The **second** test results in the the digest value of "e8530426cbabf63633ff373159247e38". This is the same value as seen in openssl using the following C source code (`gcc test.c -lcrypto`):
```
#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>
void str2hex(char *, char*, int);
void printBytes(unsigned char *, size_t );
int main() {
unsigned char *aad, *pt, *key, *nonce;
int Klen, Alen, Nlen, Plen, Tlen, Clen;
int outl = 0;
key = "439fd5c3b76587d5a601ba6ef8fad214";
aad = "eae252f42d2c71";
nonce = "ed1d316d0834d174c1b5b438";
pt = "";
Klen = strlen(key) / 2;
Alen = strlen(aad) / 2;
Nlen = strlen(nonce) / 2;
Plen = strlen(pt) / 2;
Tlen = 16;
Clen = Plen + Tlen;
unsigned char keyy[Klen], aadd[Alen], noncee[Nlen], ptt[Plen];
unsigned char ct[Clen], dt[Plen];
str2hex(key, keyy, Klen);
str2hex(pt, ptt, Plen);
str2hex(aad, aadd, Alen);
str2hex(nonce, noncee, Nlen);
EVP_CIPHER_CTX* ctx = EVP_CIPHER_CTX_new();
EVP_CIPHER_CTX_init(ctx);
EVP_EncryptInit(ctx, EVP_aes_128_ccm(), 0, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_IVLEN, Nlen, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_TAG, Tlen, 0);
EVP_EncryptInit(ctx, 0, keyy, noncee);
EVP_EncryptUpdate(ctx, 0, &outl, 0, Plen);
EVP_EncryptUpdate(ctx, 0, &outl, aadd, Alen);
EVP_EncryptUpdate(ctx, ct, &outl, ptt, Plen);
EVP_EncryptFinal(ctx, &ct[outl], &outl);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_GET_TAG, Tlen, ct + Plen);
printf("plaintext' = %s", pt);
printf("\n");
printf("\nciphertext : ");
printBytes(ct, Clen);
EVP_DecryptInit(ctx, EVP_aes_128_ccm(), 0, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_IVLEN, Nlen, 0);
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_CCM_SET_TAG, Tlen, ct + Plen);
EVP_DecryptInit(ctx, 0, keyy, noncee);
EVP_DecryptUpdate(ctx, 0, &outl, 0, Plen);
EVP_DecryptUpdate(ctx, 0, &outl, aadd, Alen);
EVP_DecryptUpdate(ctx, dt, &outl, ct, Plen);
EVP_DecryptFinal(ctx, &dt[outl], &outl);
printf("plaintext : ");
printBytes(dt, Plen);
return 0;
}
void str2hex(char *str, char *hex, int len) {
int tt, ss;
unsigned char temp[4];
for (tt = 0, ss = 0; tt < len, ss < 2 * len; tt++, ss += 2) {
temp[0] = '0';
temp[1] = 'x';
temp[2] = str[ss];
temp[3] = str[ss + 1];
hex[tt] = (int) strtol(temp, NULL, 0);
}
}
void printBytes(unsigned char *buf, size_t len) {
int i;
for (i = 0; i < len; i++) {
printf("%02x", buf[i]);
}
printf("\n");
}
```
However, the **first** test does not succeed. Pike produces the digest "7a627cad3a11cb4192566a040d801fa8", while the C code (edited accordingly) produces the expected result, "5c71b4f069cfa13b7634db4b13e7be7d".
The following Pike code annotates my concerns:
```
int main() {
mixed state1 = Crypto.AES.CCM.State();
state1->set_encrypt_key(String.hex2string("1a44f3550688fddbc1e5041dc98952c0"));
state1->set_iv(String.hex2string("5d2904298f668ba95eaa1797"));
state1->update(String.hex2string("d55908958b70abee81054cdf3d3df5"));
string ct1 = state1->crypt(String.hex2string(""));
string dig1 = state1->digest();
if(String.string2hex(dig1) != "5c71b4f069cfa13b7634db4b13e7be7d")
write("First one did not match. Got %s, expected %s.\n", String.string2hex(dig1), "5c71b4f069cfa13b7634db4b13e7be7d");
mixed state2 = Crypto.AES.CCM.State();
state2->set_encrypt_key(String.hex2string("439fd5c3b76587d5a601ba6ef8fad214"));
state2->set_iv(String.hex2string("ed1d316d0834d174c1b5b438"));
state2->update(String.hex2string("eae252f42d2c71"));
string ct2 = state2->crypt(String.hex2string(""));
string dig2 = state2->digest();
if(String.string2hex(dig2) != "e8530426cbabf63633ff373159247e38")
write("Second one did not match. Got %s, expected %s.\n", String.string2hex(dig2), "e8530426cbabf63633ff373159247e38");
}
```
I have no explanation for the incorrect results, unfortunately.
Any support is welcome.
Thank you.Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10075Crypto.DSA infinite loop in pkcs_verify()2022-03-01T13:41:06ZJoshua RogersCrypto.DSA infinite loop in pkcs_verify()Hi there,
While doing some tests of Crypto.DSA, I've come across two (likely related) cases of a call to `Crypto.DSA.State()->pkcs_verify()` resulting in an infinite loop in Gmp.
I have two test-cases. One is where `sign` is empty:
```...Hi there,
While doing some tests of Crypto.DSA, I've come across two (likely related) cases of a call to `Crypto.DSA.State()->pkcs_verify()` resulting in an infinite loop in Gmp.
I have two test-cases. One is where `sign` is empty:
```
int main() {
mixed state1 = Crypto.DSA.State();
state1->set_public_key(Gmp.mpz("008f7935d9b9aae9bfabed887acf4951b6f32ec59e3baf3718e8eac4961f3efd3606e74351a9c4183339b809e7c2ae1c539ba7475b85d011adb8b47987754984695cac0e8f14b3360828a22ffa27110a3d62a993453409a0fe696c4658f84bdd20819c3709a01057b195adcd00233dba5484b6291f9d648ef883448677979cec04b434a6ac2e75e9985de23db0292fc1118c9ffa9d8181e7338db792b730d7b9e349592f68099872153915ea3d6b8b4653c633458f803b32a4c2e0f27290256e4e3f8a3b0838a1c450e4e18c1a29a37ddf5ea143de4b66ff04903ed5cf1623e158d487c608e97f211cd81dca23cb6e380765f822e342be484c05763939601cd667", 16), Gmp.mpz("00baf696a68578f7dfdee7fa67c977c785ef32b233bae580c0bcd5695d", 16), Gmp.mpz("16a65c58204850704e7502a39757040d34da3a3478c154d4e4a5c02d242ee04f96e61e4bd0904abdac8f37eeb1e09f3182d23c9043cb642f88004160edf9ca09b32076a79c32a627f2473e91879ba2c4e744bd2081544cb55b802c368d1fa83ed489e94e0fa0688e32428a5c78c478c68d0527b71c9a3abb0b0be12c44689639e7d3ce74db101a65aa2b87f64c6826db3ec72f4b5599834bb4edb02f7c90e9a496d3a55d535bebfc45d4f619f63f3dedbb873925c2f224e07731296da887ec1e4748f87efb5fdeb75484316b2232dee553ddaf02112b0d1f02da30973224fe27aeda8b9d4b2922d9ba8be39ed9e103a63c52810bc688b7e2ed4316e1ef17dbde", 16), Gmp.mpz("1e77f842b1ae0fcd9929d394161d41e14614ff7507a9a31f4a1f14d22e2a627a1f4e596624883f1a5b168e9425146f22d5f6ee28757414714bb994ba1129f015d6e04a717edf9b530a5d5cab94f14631e8b4cf79aeb358cc741845553841e8ac461630e804a62f43676ba6794af66899c377b869ea612a7b9fe6611aa96be52eb8b62c979117bbbcca8a7ec1e1ffab1c7dfcfc7048700d3ae3858136e897701d7c2921b5dfef1d1f897f50d96ca1b5c2edc58cada18919e35642f0807eebfa00c99a32f4d095c3188f78ed54711be0325c4b532aeccd6540a567c327225440ea15319bde06510479a1861799e25b57decc73c036d75a0702bd373ca231349931", 16));
state1->pkcs_verify(String.hex2string("313233343030"), Crypto.SHA224, "");
}
```
and the other is when it is non-empty:
```
int main() {
mixed state1 = Crypto.DSA.State();
state1->set_public_key(Gmp.mpz("008f7935d9b9aae9bfabed887acf4951b6f32ec59e3baf3718e8eac4961f3efd3606e74351a9c4183339b809e7c2ae1c539ba7475b85d011adb8b47987754984695cac0e8f14b3360828a22ffa27110a3d62a993453409a0fe696c4658f84bdd20819c3709a01057b195adcd00233dba5484b6291f9d648ef883448677979cec04b434a6ac2e75e9985de23db0292fc1118c9ffa9d8181e7338db792b730d7b9e349592f68099872153915ea3d6b8b4653c633458f803b32a4c2e0f27290256e4e3f8a3b0838a1c450e4e18c1a29a37ddf5ea143de4b66ff04903ed5cf1623e158d487c608e97f211cd81dca23cb6e380765f822e342be484c05763939601cd667", 16), Gmp.mpz("00baf696a68578f7dfdee7fa67c977c785ef32b233bae580c0bcd5695d", 16), Gmp.mpz("16a65c58204850704e7502a39757040d34da3a3478c154d4e4a5c02d242ee04f96e61e4bd0904abdac8f37eeb1e09f3182d23c9043cb642f88004160edf9ca09b32076a79c32a627f2473e91879ba2c4e744bd2081544cb55b802c368d1fa83ed489e94e0fa0688e32428a5c78c478c68d0527b71c9a3abb0b0be12c44689639e7d3ce74db101a65aa2b87f64c6826db3ec72f4b5599834bb4edb02f7c90e9a496d3a55d535bebfc45d4f619f63f3dedbb873925c2f224e07731296da887ec1e4748f87efb5fdeb75484316b2232dee553ddaf02112b0d1f02da30973224fe27aeda8b9d4b2922d9ba8be39ed9e103a63c52810bc688b7e2ed4316e1ef17dbde", 16), Gmp.mpz("1e77f842b1ae0fcd9929d394161d41e14614ff7507a9a31f4a1f14d22e2a627a1f4e596624883f1a5b168e9425146f22d5f6ee28757414714bb994ba1129f015d6e04a717edf9b530a5d5cab94f14631e8b4cf79aeb358cc741845553841e8ac461630e804a62f43676ba6794af66899c377b869ea612a7b9fe6611aa96be52eb8b62c979117bbbcca8a7ec1e1ffab1c7dfcfc7048700d3ae3858136e897701d7c2921b5dfef1d1f897f50d96ca1b5c2edc58cada18919e35642f0807eebfa00c99a32f4d095c3188f78ed54711be0325c4b532aeccd6540a567c327225440ea15319bde06510479a1861799e25b57decc73c036d75a0702bd373ca231349931", 16));
state1->pkcs_verify(String.hex2string("3130353336323835353638"), Crypto.SHA256, String.hex2string("a2184515521e4c5d26f05590543c696ca2bd04b7754a18107d7f62744fbcb3a52ee80de3dca53339c3f6b2196afe3c540adfeb92686029f2"));
}
```
Unfortunately, I'm not able to offer any suggestions as to why this happens, but please let me know if you have any questions.
Cheers,
JoshPike 8.0