pike issueshttps://git.lysator.liu.se/pikelang/pike/-/issues2024-02-17T17:35:37Zhttps://git.lysator.liu.se/pikelang/pike/-/issues/3The image module is compiled with -fpic when it should be compiled with -fPIC...2024-02-17T17:35:37ZPeter BortasThe image module is compiled with -fpic when it should be compiled with -fPIC on Linux RH 6.2/sparc.Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3
Reported by @grubba
```
From: Eric Doutreleau <Eric.Doutreleau@int-evry.fr>
Date: Fri, 7 Jul 2000 16:46:15 +0200 (CEST)
Subject: problems for compiling pikev7.0.36 on s...Imported from http://bugzilla.roxen.com/bugzilla/show_bug.cgi?id=3
Reported by @grubba
```
From: Eric Doutreleau <Eric.Doutreleau@int-evry.fr>
Date: Fri, 7 Jul 2000 16:46:15 +0200 (CEST)
Subject: problems for compiling pikev7.0.36 on sparc linux redhat 6.2
```
Hello
I'm trying to compile pike v7.0.36 on my sparc linux 6.2 and i got the
following message
```
make[3]: Leaving directory
`/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings'
linking Image
encodings/encodings.a(png.o): In function `img_png_decode':
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1380:
relocation
truncated to fit: R_SPARC_GOT13 LLC50
encodings/encodings.a(png.o): In function `image_png_encode':
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1432:
relocation
truncated to fit: R_SPARC_GOT13 LLC51
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1437:
relocation
truncated to fit: R_SPARC_GOT13 LLC52
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1440:
relocation
truncated to fit: R_SPARC_GOT13 LLC53
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1445:
relocation
truncated to fit: R_SPARC_GOT13 LLC54
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1454:
relocation
truncated to fit: R_SPARC_GOT13 LLC55
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/png.c:1460:
relocation
truncated to fit: R_SPARC_GOT13 LLC56
[.....]
lots of similar messages
[...]
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/tim.c:339:
relocation
truncated to fit: R_SPARC_GOT13 LLC28
/home/glopglop/Pike-v7.0.36/src/modules/Image/encodings/tim.c:339:
relocation
truncated to fit: R_SPARC_GOT13 image_tim_f_decode_header
collect2: ld returned 1 exit status
Linking failed:
/home/glopglop/Pike-v7.0.36/bin/smartlink
/home/glopglop/Pike-v7.0.36/src/smartlink gcc -shared -o module.so
image_module.o image.o font.o matrix.o blit.o pattern.o dct.o operator.o
colortable.o polyfill.o orient.o colors.o search.o layers.o default_font.o
poly.o encodings/encodings.a -R/usr/local/lib -L/usr/local/lib
-R/usr/X11R6/lib -L/usr/X11R6/lib
/usr/lib/gcc-lib/sparc-redhat-linux/egcs-2.91.66/libgcc.a -lc
/usr/lib/gcc-lib/sparc-redhat-linux/egcs-2.91.66/libgcc.a
cp: module.so: Aucun fichier ou répertoire de ce type
make[2]: *** [dummy] Error 1
make[2]: Leaving directory `/home/glopglop/Pike-v7.0.36/src/modules/Image'
make[1]: *** [Image] Error 1
make[1]: Leaving directory `/home/glopglop/Pike-v7.0.36/src/modules'
make: *** [module_objects] Error 1
```
The compiler i use is egcs 1.1.2
Has someone succeed in compiling this version of pike in a sparc
platform with redhat 6.2
Thanks in advance
--
Eric Doutreleau
I.N.T | Tel : +33 (0) 160764687
9 rue Charles Fourier | Fax : +33 (0) 160764321
91011 Evry France | email : Eric.Doutreleau@int-evry.frPike 7.0https://git.lysator.liu.se/pikelang/pike/-/issues/10134Crypto.DSA et al verify messages with various incorrect signatures.2024-01-26T13:03:11ZJoshua RogersCrypto.DSA et al verify messages with various incorrect signatures.Hi there,
I've started to take a look at the latest master branch of Pike and [updated my script](https://github.com/operasoftware/nettle-wycheproof-testsuite) to support the newer version of Pike. A few new issues have been found.
`Cr...Hi there,
I've started to take a look at the latest master branch of Pike and [updated my script](https://github.com/operasoftware/nettle-wycheproof-testsuite) to support the newer version of Pike. A few new issues have been found.
`Crypto.DSA.State->pkcs_verify` successfully verifies a msg,sig pair with `Crypto.SHA256` and `Crypto.SHA224` which:
1. use long form encoding for the length of `r` and/or `s`.,
2. uses a length of sequence `r` and/or `s` contains a leading `0`.
Here, we see two different string representation of the signature verify as the same (both should be rejected):
```pike
int main() {
mapping(string:string) key = ([
"g" : "16a65c58204850704e7502a39757040d34da3a3478c154d4e4a5c02d242ee04f96e61e4bd0904abdac8f37eeb1e09f3182d23c9043cb642f88004160edf9ca09b32076a79c32a627f2473e91879ba2c4e744bd2081544cb55b802c368d1fa83ed489e94e0fa0688e32428a5c78c478c68d0527b71c9a3abb0b0be12c44689639e7d3ce74db101a65aa2b87f64c6826db3ec72f4b5599834bb4edb02f7c90e9a496d3a55d535bebfc45d4f619f63f3dedbb873925c2f224e07731296da887ec1e4748f87efb5fdeb75484316b2232dee553ddaf02112b0d1f02da30973224fe27aeda8b9d4b2922d9ba8be39ed9e103a63c52810bc688b7e2ed4316e1ef17dbde",
"keySize" : 2048,
"p" : "008f7935d9b9aae9bfabed887acf4951b6f32ec59e3baf3718e8eac4961f3efd3606e74351a9c4183339b809e7c2ae1c539ba7475b85d011adb8b47987754984695cac0e8f14b3360828a22ffa27110a3d62a993453409a0fe696c4658f84bdd20819c3709a01057b195adcd00233dba5484b6291f9d648ef883448677979cec04b434a6ac2e75e9985de23db0292fc1118c9ffa9d8181e7338db792b730d7b9e349592f68099872153915ea3d6b8b4653c633458f803b32a4c2e0f27290256e4e3f8a3b0838a1c450e4e18c1a29a37ddf5ea143de4b66ff04903ed5cf1623e158d487c608e97f211cd81dca23cb6e380765f822e342be484c05763939601cd667",
"q" : "00baf696a68578f7dfdee7fa67c977c785ef32b233bae580c0bcd5695d",
"type" : "DsaPublicKey",
"y" : "1e77f842b1ae0fcd9929d394161d41e14614ff7507a9a31f4a1f14d22e2a627a1f4e596624883f1a5b168e9425146f22d5f6ee28757414714bb994ba1129f015d6e04a717edf9b530a5d5cab94f14631e8b4cf79aeb358cc741845553841e8ac461630e804a62f43676ba6794af66899c377b869ea612a7b9fe6611aa96be52eb8b62c979117bbbcca8a7ec1e1ffab1c7dfcfc7048700d3ae3858136e897701d7c2921b5dfef1d1f897f50d96ca1b5c2edc58cada18919e35642f0807eebfa00c99a32f4d095c3188f78ed54711be0325c4b532aeccd6540a567c327225440ea15319bde06510479a1861799e25b57decc73c036d75a0702bd373ca231349931"
]);
string msg;
string sig;
string siq;
msg = "313233343030";
sig = "30813d021d00a545d62d6e336775fb6a9b8495721646a54bd8c6173fc0a2295a1b7b021c3be6bae0e8763818840a9151ad8ed2b3b348e4a2c488d3fbdbbca844"; //use long form encoding for the length of [r, s],
siq = "3082003d021d00a545d62d6e336775fb6a9b8495721646a54bd8c6173fc0a2295a1b7b021c3be6bae0e8763818840a9151ad8ed2b3b348e4a2c488d3fbdbbca844"; //length of sequence [r, s] contains a leading 0
msg = String.hex2string(msg);
sig = String.hex2string(sig);
mixed state = Crypto.DSA.State();
state->set_public_key(Gmp.mpz(key["p"], 16), Gmp.mpz(key["q"], 16), Gmp.mpz(key["g"], 16), Gmp.mpz(key["y"], 16));
bool res = state->pkcs_verify(msg, Crypto.SHA256, sig);
if(res)
write("success!\n");
sig = String.hex2string(siq);
res = state->pkcs_verify(msg, Crypto.SHA256, sig);
if(res)
write("success!\n");
return 0;
}
```
This seems similar to https://git.lysator.liu.se/pikelang/pike/-/issues/10077, and I'm not sure why I didn't pick it up ealier.
Cheers,
JoshPike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10139RSA PKCS1 v1.5 decryption implementation does not detect ciphertext modificat...2024-01-26T13:03:11ZJoshua RogersRSA PKCS1 v1.5 decryption implementation does not detect ciphertext modification by prepending \0-bytes to ciphertextsHi there,
Another issue in RSA PKCS1 v1.5. Pike does not bork on ciphertexts that have been modified with prepended 0-bytes in their ciphertext.
A small test-case:
```
int main() {
string key = "30820943020100300d06092a864886f70d010...Hi there,
Another issue in RSA PKCS1 v1.5. Pike does not bork on ciphertexts that have been modified with prepended 0-bytes in their ciphertext.
A small test-case:
```
int main() {
string key = "30820943020100300d06092a864886f70d01010105000482092d308209290201000282020100f601be0dccd04aa40b12f3f191ae17c1f9c8c0b68e7a77e14be25c3c7907cb1d33a6ef418ef41852f32c98392bc5c9aed91c1a1501c503eab89b3ee6f4f8eb2e0fcfc41bd03609cf6a8eb3aa6f0fbe23187b33db4d34b66d128a8aba0a2abf40bb9d13d8e2554569a57ab1d8c61b8cad2dc88599ae0da5346e15dace1bac7bf69737c22f083be9b46bb8b1eab5957b2da740275e96c87195b96fe11452159dafcfd916cee5d749a77bc3905a5ebd387ae445e8fe70f16e9a086639779ceffbfd41557bd99aea6a371a6b4b160615a1a12bc6958d34bce0c85adcbd8392fa10ceca52209d56196ba3d273ce228f1f111192aa92de2a039798a17bcecb4dc6100e6f8ae8c2643f2ae768b2255f082c978e95ca551555f10608231cf8003bbf807969fff1e51914b9a8c9b8f4564645b9e5d705ffad29663f5dae3d76652b422e43f13e6c1491090805c2d1268a74a251177427e33a9a91175c3670b91746008bce1fd231e6e4f2ad70cb43aca5f07600a6d31dd02915243dfdd943a02165da367a6b7e4dae1dd2e8b836903080795d2585076cc1c15dd9e8d2e5e047526569b1bfd395d957eb9fde325d342d14426e71efdc1887515e53cdea5834921f928629e748eed097ac4024e2bf255d70411f87373948cf8e8aa7effa2b0ab47d5166091e1aedec60568b155bd9c27bc55f3ece35f83d636dbcd5abf4853a051db94d5045020301000102820200065028224431ca35e87f82d97302c9384b4d341385ecd8510f4df94e51facf0dbfa01694139e3f00e34859db09bd087e74b2e1c1229652e73df7e49c2fb2dd9cda7f5b49d81a32e9403e4b97b6eeebfdb6e89e7d8fbf27b95282fca9668e649c68297bf367bcdc21a86dfc22132a177e4591024b5dd49ad091775271fc9d7cb6e8cd8a5858f93f4cf280bf0c1b69d675e6f760ab443fa8ee8ddf89a2a85d46a52c367c27db6d1ec6435e52eb86c7e0ab02b05543865423cc4f25346f55e1db6675e69832e43a04ccc78af3abd68477ed37698ab7f61facbdbcdb32552de5e89d8342aa9f445b8afac81bfc5bc05981ea20b340e948f710f7b3ee85f18b5c3c5832f2336706c5e9c9bd8e43d202e73a0f62776df4b715975eddd31aa643b14145057b4995556de614c57b33297bda0e05a8b8882a29563bf21686ce34c3960f905de73911987eb696e07eac0a63857e2894c3b4629477ecbf1fc76eafbb2ce4a0f00f8cdb6fbd6169e399151460522cf5b365d9bbb9587d07dac8c438982adea9ff243a86bbdf128eaa0d3a88871d8cdf081854258a651ff4226ee9749b4a6add090c159ccea06b9a10804e5fe15120cc63a5972eab0e43980dedaff321fadeea3ca60c3ba1c2980bb597ea783b80ab6eba87feb5754fd1d65d7cad6f81cf52c1a6bfebf9a75e9a316cb364d8cf467d96370871df2ee66ee1c1694a02239583910282010100fc21b855c5ad4ca2b6970516406f71c6e79efc4126e6598772db1e082de6b0dddaaa2a2951f04148e86e0bde28213b7f600f987308301eacea134062bb0c3ddf628da9abf93ef1ce3e75b0953a484dbd3554bd5c0649933dd77e527563e90f05a8013fddac958c329378e94303b304be5f9df1fe5b043a7fdd94700a3f0b1cbbd0516b7cd94c57ca96d9fd2a8ca973991218cba33a1c23d810f7519d1f7702ab72affdb3f84a1b2a88116e4033bc4d0cfc7989c657e0fe94e964476ae58bae6b7876f36c09d32b1a63f8c47c94a74c92eedf75fc27cffe0f8452363e4bc8f7653f3cb55eaf693cec70d13c875de935a8b20439ab7e93f76981c5957fc5bb44d90282010100f9c7f748a505d23ecef9a85f8097c8cf7d7028ef6c90e22a336511582d2cc3636e34ead37204dbd22f142a3fb1d5f857b0310c7a433f51ae14d4608b01b43aa8c7ae67835f7fbe0b9d97948b39e9ba2d3a1687edb8b56ee70ff0536dab4d0551f71ed0daee9e412449f5f099bcc15e4ef0554dc79f87fec5a0dea717c7054392bf444613937401bbef3c22fbf7e738c58779b981609a1f9c11dd6f0bbe9996e2773459e4cef247b02a9fc21296ac57a5b10561824310cfbdecc90e06598370e3698713fdbe2528ec4ef3dccaae701eedc3e54ad6e7af4e68e3b39bd2e97ac9119936c647a503511cb283df984cfd7c07f0f56aa8ae3166948ef3f41b0859934d0282010100815486aab0a0896bf97f13e3eb1f7f5c49195b49cc3b6277412a3688798b18f46422df479cb941b3b54e25964a3d69b897bcc8355160e58b4af29f1745dd2cabb670f634b9c058e6b3514947f2c27de5ed424f73b1e1f1be4a188911a0333f3a6688658b3ee8e3265a512e4deacadc470ee304ebb5224123afb461984fe8524fe0b6b30d32a59f6ed2dc74a96bc7cbfd1bb44e58a7092235c5d6272e12a2c862cb8c8cf5d109aa4fb1c6472875a14460c1ed5207c4b22bc494c7947eb7ca63a8cafd31361d000ddf16a2d79f13dd9140d979149b488cbf44945a5b6aaf13221bf4491ebbb7fca27ca20e221f49c3c37b89fcf2dc0e2cb63f8f8a9b7a142250590282010100b61d84ff934a4e437b16ee1b4b9fdf4ae13370b5385bde7a5464a123c0343df575f9e128ef9df944230d39cc9cf5dc0edb28b7e740b69ef024c1bfee39fcd5340ffaea0010160c535dc0920e7cd81be533d00fa554a1fc4d3e02c461569f5e7ca787f1515edf45b196b759884de652c38d5934cf92524e807b4d3b590bc39bc417ee4885a761d28ddadce6c8fdb3b961d3e7fd48064df9340a967f8b79997438841f48579a476ddb55088c308f68f2b29d01c6597a5a7c8d066284f63e37a68c3879c32aa3836675fd0eb2719883a91944561e9dd7e8aa6bb17157f08c48f8e6fae5c3e5a2bb6b5d580eec6c97ddcd9be0a49ef283a7031ad7aba8d438df4e950282010022fb8e5fcd9b767104e71244db53058c18061e1b0d1f63b73e2d59a95e2a10cd87426a33da13c287cdef8136e5e47e93fb9b30ad92628a7b543f48eb011a86356ab3cb480f27e391b018ca187d97af3d82e31861ecafa663db78aa89c3bd468e6aadefb3a43f78bc00b8014c95db54e9d21a017e8f21f671545edde9a965ea32dfff45cda37fca1aa5132f6c8eed222bd01fed5a6e7d639580c5955777a86544c2c4c939bdb8b4c486dda53072861a0334359bdb3758475e49d90d0539944e78cfcfd8fff55bb31a1cebc65b28f51e790701b2f7912188984f034e6e96e1c5251e33fe38fb221bce7a90a86857c5f56b6ca77307c45d5290b1f088ade082b349";
string privateKeyPkcs8 = String.hex2string(key);
mixed state = Standards.PKCS.parse_private_key(privateKeyPkcs8);
string ret;
string ct = String.hex2string("e4b9d12b1519d15af3a10fef8ed37f918e998c56b7d89fad34cecd08ecb9ae9b3213f1e9686be7ea525882a5f28a594963b4c16ed9207210646d0d5cac26920f92edd61b262a39f0f9a9f889da6f583c6fce47a08b0fd575b4bbd33e64da0eb390703e341ae3c4392b39360a1a623b8701ad51801e63df43237df4e816f2a1e4312099f1070c528fc10803879321e99e76104b2440cb4ca788c2eeda15a673e418ff247f8556a2c5be47bc016fc6a2a6caf4080d6004f4d8d17dae33e23c8bb4046fd91ea85560f9d68949da790ea662e32c3c44538d4a8bd555338ddbf4009a9d8b2cb42337ab138b6841c0f1d34f585ecb9c8be41a037fd79c3db489909da1328a170a4d676d62359166ba641d4ab0e6d56f26903e41dd4307742d6e76c67b88ac2f835a9d5b45de31a5e4b479e76b82b08c184a67f2b917c2f76ba8ebfe98b0071eee383de77cb5b06050eb058a5194eb8170b000b47862bf40c1baacb0e4c58210284556aee1ba1006f25618bece2e9578fb73fd389914db94343b41c407c7778e49b3aa3062c92c63e83d79aac7c7f3d1334f197b8660432f29504c6f1477f9d00a3cf56b6bba97ffbcbb5c68cd60972982bdc910419ec69bcc1cde7cdb1516706e7a51fb23da821754fc2385ccbc85ced7c7a32b9a0fd7fa71b9829a86247d1a0942546b25109079a7be7b2bff81803cd96102cdeead406b2446077b6e00");
array err = catch { ret = state->decrypt(ct); };
if(ret)
write("%s\n", ret);
}
```
This issue is similar to CVE 2020-14967, which also allowed for the prepending of \0-bytes to the ciphertext (which resulted in a buffer overflow due to difference in the expected and real length of the ct).
Cheers,
JoshPike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10136Private getter not marked as used.2023-11-16T12:02:24ZHenrik (Grubba) GrubbströmPrivate getter not marked as used.Reported by Pontus Östlund:
```
$ cat bug-private-getter.pike
class Test {
private string `property_accessor() {
return "I'm private";
}
private string `unused_getter() {
return "Unused private getter";
}
public void...Reported by Pontus Östlund:
```
$ cat bug-private-getter.pike
class Test {
private string `property_accessor() {
return "I'm private";
}
private string `unused_getter() {
return "Unused private getter";
}
public void log() {
werror("Log: %s\n", property_accessor);
}
}
int main() {
Test t = Test();
t->log();
}
```
In current Pike 8.0:
```
$ ./pike bug-private-getter.pike
bug-private-getter.pike:2: Warning: Modifier mismatch for variable property_accessor.
bug-private-getter.pike:6: Warning: Modifier mismatch for variable unused_getter.
bug-private-getter.pike:13: Warning: `property_accessor is private but not used anywhere.
bug-private-getter.pike:13: Warning: unused_getter is private but not used anywhere.
bug-private-getter.pike:13: Warning: `unused_getter is private but not used anywhere.
Log: I'm private
```
In current Pike master:
```
$ ./pike bug-private-getter.pike
bug-private-getter.pike:13: Warning: `property_accessor is private but not used anywhere.
bug-private-getter.pike:13: Warning: unused_getter is private but not used anywhere.
bug-private-getter.pike:13: Warning: `unused_getter is private but not used anywhere.
Log: I'm private
```Pike Nexthttps://git.lysator.liu.se/pikelang/pike/-/issues/8010Pike.identify_cycle doesn't handle declared-only __hash member2023-11-05T10:13:18ZPeter BortasPike.identify_cycle doesn't handle declared-only __hash memberImported from https://youtrack.roxen.com/issue/PIKE-10
Reported by Martin Karlgren <marty@roxen.com>
Pike.identify_cycle throws when a class has a declared, but not defined, __hash member. (Not sure if the problem really is in hash_sva...Imported from https://youtrack.roxen.com/issue/PIKE-10
Reported by Martin Karlgren <marty@roxen.com>
Pike.identify_cycle throws when a class has a declared, but not defined, __hash member. (Not sure if the problem really is in hash_svalue?)
```
> class Foo { mixed bar; int __hash(); }
> class Bar { mixed foo; }
> Foo foo = Foo();
> Bar bar = Bar();
> foo->bar = bar;
(1) Result: HilfeInput()->Bar()
> bar->foo = foo;
(2) Result: HilfeInput()->Foo()
> Pike.identify_cycle(foo);
Calling undefined function.
HilfeInput:1: HilfeInput()->Foo()->__hash()
-:1: __builtin.identify_cycle(HilfeInput()->Foo())
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10037Dumping failure of 7.8::SSL.session2023-11-05T09:31:19ZMarcus ComstedtDumping failure of 7.8::SSL.sessionI noticed this dumping failure in the pikefarm builds of bahamut, but it can be reproduced on any system. Presumably the dump works if 8.0::Crypto has been dumped first, since most pikefarm systems do not hit the issue...
``` shell
hak...I noticed this dumping failure in the pikefarm builds of bahamut, but it can be reproduced on any system. Presumably the dump works if 8.0::Crypto has been dumped first, since most pikefarm systems do not hit the issue...
``` shell
hakua:~/Pike/8.1/build/linux-5.4.41-ppc64% /home/marcus/Pike/8.1/build/linux-5.4.41-ppc64/pike -DNOT_INSTALLED -DPRECOMPILED_SEARCH_MORE -m/home/marcus/Pike/8.1/build/linux-5.4.41-ppc64/master.pike -x dump -t /tmp/dumptest ../../lib/7.8/modules/SSL.pmod/session.pike
#### ../../lib/7.8/modules/SSL.pmod/session.pike:
Cannot find 8.0::Crypto.CompatProxy() in 8.0::Crypto.
master.pike:5697:
master()->Encoder()->find_index(8.0::Crypto,8.0::Crypto.CompatProxy(),({0}),UNDEFINED)
master.pike:5924:
master()->Encoder()->nameof(@0=8.0::Crypto.CompatProxy(),@1=({0}))
master.pike:5916:
master()->Encoder()->nameof(8.0::Crypto.CompatProxy()->Buffer,({0}))
master.pike:5965:
master()->Encoder()->nameof(8.0::Crypto.CompatProxy()->Buffer->State,UNDEFINED)
/home/marcus/Pike/8.1/lib/modules/Tools.pmod/Standalone.pmod/dump.pike:221:
Tools.Standalone.dump()->dumpit("../../lib/7.8/modules/SSL.pmod/session.pike","/tmp/dumptest/session.pike")
/home/marcus/Pike/8.1/lib/modules/Tools.pmod/Standalone.pmod/dump.pike:355:
Tools.Standalone.dump()->dump_files()
-:1: Pike.Backend(0)->`()(3600.0)
hakua:~/Pike/8.1/build/linux-5.4.41-ppc64%
```
The failure in nameof() can be reproduced separately, although I'm not sure if this is supposed to work or not (CompatProxy is protected in 8.0::Crypto):
```
Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend)
> 8.0::Crypto.Buffer;
(1) Result: 8.0::Crypto.CompatProxy()->Buffer->State
> master()->nameof(8.0::Crypto.Buffer);
Cannot find 8.0::Crypto.CompatProxy() in 8.0::Crypto.
master.pike:5697:
master()->find_index(8.0::Crypto,8.0::Crypto.CompatProxy(),({0}),UNDEFINED)
master.pike:5924: master()->nameof(@0=8.0::Crypto.CompatProxy(),@1=({0}))
master.pike:5916: master()->nameof(8.0::Crypto.CompatProxy()->Buffer,({0}))
master.pike:5965:
master()->nameof(8.0::Crypto.CompatProxy()->Buffer->State,UNDEFINED)
>
```Henrik (Grubba) GrubbströmHenrik (Grubba) Grubbströmhttps://git.lysator.liu.se/pikelang/pike/-/issues/10129System.TM timezone confusion2023-11-04T09:09:09ZHenrik (Grubba) GrubbströmSystem.TM timezone confusionFrom LysLysKOM 26017901:
```
26017901 2023-10-12 17:13 /39 rader/ ceder (-) Per Cederqvist
Mottagare: Pike (-) developers forum <21425>
Ärende: System.TM timezone confusion
------------------------------------------------------------
``...From LysLysKOM 26017901:
```
26017901 2023-10-12 17:13 /39 rader/ ceder (-) Per Cederqvist
Mottagare: Pike (-) developers forum <21425>
Ärende: System.TM timezone confusion
------------------------------------------------------------
```
System.TM does not work as advertised. The documentation says that
the timezone will be UTC when you supply a number to the constructor,
but that does not appear to be the case. Note how the timezone is
CEST no matter how I initialize the TM object, but the reported hours
differ:
```
$ pike
Pike v9.0 release 1 running Hilfe v3.5 (Incremental Pike Frontend)
> mixed t = System.TM(1697121800);
> t;
(1) Result: System.TM(Thu Oct 12 15:43:20 2023 CEST)
> t->gmtime(1697121800);
(2) Result: 1
> t;
(3) Result: System.TM(Thu Oct 12 15:43:20 2023 CEST)
> t->localtime(1697121800);
(4) Result: 1
> t;
(5) Result: System.TM(Thu Oct 12 16:43:20 2023 CEST)
```
The result (5) makes sense: it matches what I would expect. But
the hour should be set to 14, not 15:
```
> mixed c = Calendar.ISO.Second(1697121800);
> c->set_timezone("UTC");
> c;
(5) Result: Second(Thu 12 Oct 2023 16:43:20 CEST)
> mixed u = c->set_timezone("UTC");
> u;
(6) Result: Second(Thu 12 Oct 2023 14:43:20 UTC)
```
This also agrees with my private utility for converting a time_t value
to the local timezone and UTC (this one is written in Python):
```
$ time_t2date 1697121800
2023-10-12 16:43:20 CEST
2023-10-12 14:43:20 GMT
```
Tested on the current master, and a few older Pike versions.
```
(26017901) /ceder (-) Per Cederqvist/---------------
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10133__ARGS__ broken in recent Pike master2023-10-31T09:34:40ZHenrik (Grubba) Grubbström__ARGS__ broken in recent Pike masterPike developers mailinglist/LysLysKOM 26044077:
```
26047339 2023-10-30 00:48 /21 rader/ Chris Angelico <rosuav@gmail.com>
Sänt av: SRS0=Zs/b=GL=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-10-30 00:48 av Brevb...Pike developers mailinglist/LysLysKOM 26044077:
```
26047339 2023-10-30 00:48 /21 rader/ Chris Angelico <rosuav@gmail.com>
Sänt av: SRS0=Zs/b=GL=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Importerad: 2023-10-30 00:48 av Brevbäraren
Extern mottagare: Pike Developers <pike-devel@lists.lysator.liu.se>
Mottagare: Pike (-) developers forum <21435>
Ärende: Pike 9.0 quirk with implicit lambda
```
------------------------------------------------------------
```
void call(function cb) {cb(42);}
int main() {
werror("Pike version %O:\n", __VERSION__);
call() {
werror("Args: %O\n", __ARGS__);
mixed value = 1234;
werror("%O\n", lambda() {werror("%O\n", value);});
};
return 0;
}
```
In Pike 8 (tested on 8.1.15), the implicit lambda correctly receives
its `__ARGS__`, and will happily provide those as closure variables. In
Pike 9 (tested with current master, 235eb5), the inner function
somehow causes `__ARGS__` to be 0 instead of an array.
Any ideas as to what's going on here? Am I misusing implicit lambdas?
ChrisA
```
(26047339) /Chris Angelico <rosuav@gmail.com>/------
```Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10111Calendar module in Pike 8.0 is broken near 1900-01-01T00:00:00 in some timezo...2023-08-22T10:59:14ZHenrik (Grubba) GrubbströmCalendar module in Pike 8.0 is broken near 1900-01-01T00:00:00 in some timezones.```
$ TZ=UTC pike
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 UTC)
$ TZ=Europe/Stockholm pike
Pike v8.0 release 1738 running Hil...```
$ TZ=UTC pike
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 UTC)
$ TZ=Europe/Stockholm pike
Pike v8.0 release 1738 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
Failed to dwim time from "19000101T000000"
/usr/lib64/pike/modules/Calendar.pmod/YMD.pike:3303:
ISO.dwim_time("19000101T000000",UNDEFINED)
> Calendar.dwim_time("19000101T000013");
Failed to dwim time from "19000101T000013"
/usr/lib64/pike/modules/Calendar.pmod/YMD.pike:3303:
ISO.dwim_time("19000101T000013",UNDEFINED)
> Calendar.dwim_time("19000101T000014");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 CET)
> Calendar.dwim_time("18991231T23:59:59");
(2) Result: Second(Sun 31 Dec 1899 23:59:59 SET)
> Calendar.dwim_time("19000101T000015");
(3) Result: Second(Mon 1 Jan 1900 0:00:01 CET)
```
Note that when the parsing succeeds, the resulting seconds count is off by 14 seconds.
The above works fine in Pike 9.0 (aka master):
```
$ TZ=Europe/Stockholm ./pike
Pike v9.0 release 0 running Hilfe v3.5 (Incremental Pike Frontend)
> Calendar.dwim_time("19000101T000000");
(1) Result: Second(Mon 1 Jan 1900 0:00:00 CET)
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10121Filesystem.System()->find() is broken.2023-08-22T10:59:14ZHenrik (Grubba) GrubbströmFilesystem.System()->find() is broken.The filtering of in `find()` attempts to call the value `1` (if there are any subdirectories). This seems to be code that was missed in 9ae59318485754881ba0798de5dfac12c1abede9:
```
array find(void|function(Filesystem.Stat, __unknown__.....The filtering of in `find()` attempts to call the value `1` (if there are any subdirectories). This seems to be code that was missed in 9ae59318485754881ba0798de5dfac12c1abede9:
```
array find(void|function(Filesystem.Stat, __unknown__...:int) mask,
mixed ... extra)
{
array(Filesystem.Stat) res = ({});
array(Filesystem.Stat) d = get_stats() || ({});
array(Filesystem.Stat) r = filter(d, "isdir");
```Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/8099file_stat() on NT ought to consider settings in the register.2023-05-15T09:51:42ZPeter Bortasfile_stat() on NT ought to consider settings in the register.Imported from https://youtrack.roxen.com/issue/PIKE-99
Reported by @grubba
Match the file suffix against the values listed by
{{RegGetKeyNames(HKEY_CURRENT_USER,
"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FileExts");}}
...Imported from https://youtrack.roxen.com/issue/PIKE-99
Reported by @grubba
Match the file suffix against the values listed by
{{RegGetKeyNames(HKEY_CURRENT_USER,
"Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\FileExts");}}
to set the X-bit in `st_mode` or not.https://git.lysator.liu.se/pikelang/pike/-/issues/10078Crypto.ECC.SECP_521R1 does not verify valid signatures.2023-05-15T08:16:54ZJoshua RogersCrypto.ECC.SECP_521R1 does not verify valid signatures.Hi there,
While conducting some tests of Crypto.ECC.SECP_521R1->ECDSA(), I've come across a testcase which should be successfully verified, but it is not.
The code is as follows:
```
int main() {
string x = "00ee030cdb40abf7072686668...Hi there,
While conducting some tests of Crypto.ECC.SECP_521R1->ECDSA(), I've come across a testcase which should be successfully verified, but it is not.
The code is as follows:
```
int main() {
string x = "00ee030cdb40abf70726866681f7b7fedc534190929c05a650bb928b894a5bbfe9577eea83c6331a796fa27ed9fac95d9ecacdfef6d61c925502b0afddc671463549";
string y = "0155606dd4cab19330c57c2ee740cd9c7c88bd88d95f840f315d525379dfeb7ea9bd3677b2185b92957f374317cc6124aacc8708075c4c05c95cbbc355bd692c3708";
string msg = "313233343030";
string sig = "30818702420090c8d0d718cb9d8d81094e6d068fb13c16b4df8c77bac676dddfe3e68855bed06b9ba8d0f8a80edce03a9fac7da561e24b1cd22d459239a146695a671f81f73aaf02413ee5a0a544b0842134629640adf5f0637087b04a442b1e6a22555dc1d8b93f8784f1ddd0cf90f75944cc2cd7ae373e5c2bac356a60ff9d08adfcdba3fa1b7a9d1d";
mixed state = Crypto.ECC.SECP_521R1->ECDSA();
state->set_public_key(Gmp.mpz(x, 16), Gmp.mpz(y, 16));
if(state->pkcs_verify(String.hex2string(msg), Crypto.SHA3_512, String.hex2string(sig)))
write("Success!\n");
return 0;
}
```
The test codes from https://github.com/google/wycheproof/blob/master/testvectors/ecdsa_secp521r1_sha512_test.json#L4279, and the explanation for the test is as follows: "Some implementations of ECDSA do not handle duplication and points at infinity correctly. This is a test vector that has been specially crafted to check for such an omission"
Please note: I have not tested this in Nettle itself, because I'm not 100% sure how to use the related functions in the C code.
Thank you.https://git.lysator.liu.se/pikelang/pike/-/issues/10107Parser.Markdown: Bogus output when using code fences2023-04-07T12:55:59ZHenrik (Grubba) GrubbströmParser.Markdown: Bogus output when using code fencesIssue copied from https://github.com/pikelang/Pike/issues/40
The following code
~~~pike
constant MD = #"
## Some Stuff
```html
<head></head>
```
Some text post code fence
";
int main(int argc, array(string) argv) {
string html = ...Issue copied from https://github.com/pikelang/Pike/issues/40
The following code
~~~pike
constant MD = #"
## Some Stuff
```html
<head></head>
```
Some text post code fence
";
int main(int argc, array(string) argv) {
string html = Parser.Markdown.parse(MD);
werror("%s", html);
}
~~~
generates the following output:
```html
<h2 id="some-stuff">Some Stuff</h2>
<pre><code class='lang-html'>
<head></head>
</code></pre>
<head></head><p>Some text post code fence</p>
```
But this is what's expected:
```html
<h2 id="some-stuff">Some Stuff</h2>
<pre><code class='lang-html'>
<head></head>
</code></pre>
<p>Some text post code fence</p>
```https://git.lysator.liu.se/pikelang/pike/-/issues/10005The fdlib changes in Pike 8.0.606 broke support for sprshd on NT.2023-01-01T13:02:07ZHenrik (Grubba) GrubbströmThe fdlib changes in Pike 8.0.606 broke support for sprshd on NT.`sprshd` works as usual with Pike 8.0.604.
In Pike 8.0.606 and later it hangs when spawning the first external binary.`sprshd` works as usual with Pike 8.0.604.
In Pike 8.0.606 and later it hangs when spawning the first external binary.Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/10044Warning in 7.8::Crypto.DSA2023-01-01T12:58:10ZHenrik (Grubba) GrubbströmWarning in 7.8::Crypto.DSAThe following warning causes the testsuite to fail:
```
.../lib/7.8/modules/Crypto.pmod/DSA.pike:193: An expression of type mixed cannot be assigned to a variable of type { mpz = object(implements _static_modules.Gmp()->mpz) }.
```The following warning causes the testsuite to fail:
```
.../lib/7.8/modules/Crypto.pmod/DSA.pike:193: An expression of type mixed cannot be assigned to a variable of type { mpz = object(implements _static_modules.Gmp()->mpz) }.
```Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10073Crypto.AES.CCM Documentation Lacks IV Truncation Information2023-01-01T12:56:05ZJoshua RogersCrypto.AES.CCM Documentation Lacks IV Truncation InformationHi,
Crypto.AES.CCM currently raises an exception if a too-short (less than 7-octets) IV is set using state->set_iv().
According to https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Nettle/BlockCipher/CTR/State/set_iv....Hi,
Crypto.AES.CCM currently raises an exception if a too-short (less than 7-octets) IV is set using state->set_iv().
According to https://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Nettle/BlockCipher/CTR/State/set_iv.html, "iv must have the length reported by iv_size().".
However, a too-long IV set using set_iv() does not raise an exception, and is instead simply truncated to 13-octets:
```
if (iv_len < 7) {
Pike_error("Too short nonce for CCM. Must be at least 7 bytes.\n");
}
if (THIS->nonce) {
free_string(THIS->nonce);
THIS->nonce = NULL;
}
if (iv_len > 13) {
THIS->nonce = string_slice(iv, 0, 12);
iv_len = 13;
} else {
add_ref(THIS->nonce = iv);
}
```
As far as I can tell, this truncation is undocumented, and personally, I see no reason for it to be truncated over an exception being raised.
Can the documentation be changed and/or an exception be raised instead?
Thank you.https://git.lysator.liu.se/pikelang/pike/-/issues/10104Define the behavior of catch vis a vis local variables defined in the block.2022-12-21T15:42:21ZHenrik (Grubba) GrubbströmDefine the behavior of catch vis a vis local variables defined in the block.There exists code (eg `Parser.Tabular`) that uses exceptions for control flow, and expects variables defined in the catch block to be cleared when the catch returns. Having the variables be cleared at a later time or out of order may cau...There exists code (eg `Parser.Tabular`) that uses exceptions for control flow, and expects variables defined in the catch block to be cleared when the catch returns. Having the variables be cleared at a later time or out of order may cause the code to fail.
Consider:
```
int bangers;
#if __VERSION__ < 9.0
#define _destruct destroy
#endif
class Bang
{
inherit Pike.DestructImmediate;
protected void create()
{
bangers++;
}
protected int _destruct()
{
bangers--;
error("Bang!\n");
}
}
mixed a(int i)
{
mixed err = catch {
Bang bang = Bang();
if (i) error("Other!\n");
};
werror("#%d: Bangers: %d\n", i, bangers);
if (err) {
werror("Error: %O\n", err = describe_error(err));
} else {
werror("No error.\n");
}
return err;
}
int main()
{
for (int i = 0; i < 2; i++) {
mixed err = catch {
mixed val = a(i);
werror("#%d: bangers: %d, val: %O\n", i, bangers, val);
};
if (err) {
werror("#%d: a(%d) failed: %O\n", i, i, describe_error(err));
}
}
}
```
This issue causes the `Parser.Tabular` testsuite to hang.Pike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10033Operator assignment and strict_types2022-11-21T10:00:53ZHenrik (Grubba) GrubbströmOperator assignment and strict_typesFrom the Pike developers mailinglist:
```
22509896 2018-03-26 17:36 -0700 /41 lines/ Marc Simpson <marc@0branch.com>
Sender: SRS0+w18L=GR=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Imported: 2018-03-27 02:36 av Brevbäraren
Ex...From the Pike developers mailinglist:
```
22509896 2018-03-26 17:36 -0700 /41 lines/ Marc Simpson <marc@0branch.com>
Sender: SRS0+w18L=GR=lists.lysator.liu.se=pike-devel-bounces@lysator.liu.se
Imported: 2018-03-27 02:36 av Brevbäraren
External recipient: pike-devel@lists.lysator.liu.se
To: Pike (-) developers forum <20565>
Subject: Operator assignment and strict_types
```
Hi folks,
It looks like operator assignment (op=), increment and decrement
statements aren't subjected to the same typechecks as their more
explicit equivalents.
For example, neither the post-increment nor += statements below warn
with strict_types enabled, even though they assign values outside of
foo's restricted int domain:
int(3..3) foo = 3;
foo++; // no warning
foo += 1; // no warning
foo = foo + 1; // warning from strict_types
Similarly, operator assignment on aggregates fails to elicit a warning:
array(int) a = ({});
multiset(int) b = (<>);
mapping(int:int) c = ([]);
// no warnings
a += ({ "hey" });
b += (< "hey" >);
c += ([ "hey": "there" ]);
// warnings from strict_types
a = a + ({ "hey" });
b = b + (< "hey" >);
c = c + ([ "hey": "there" ]);
I'm guessing this is because the checks provided by the
F_ASSIGN/F_ASSIGN_SELF case (las.c) only apply to direct assignment;
op= and friends are presumably not instrumented for strict_types in
the same manner.
Have there been any discussions around addressing this inconsistency?
Thanks,
MarcPike 9.0https://git.lysator.liu.se/pikelang/pike/-/issues/10094Standards.IIM.get_information() returns ([]) for some files that have IPTC-II...2022-11-16T10:16:08ZHenrik (Grubba) GrubbströmStandards.IIM.get_information() returns ([]) for some files that have IPTC-IIM metadata.```
Pike v8.0 release 1783 running Hilfe v3.5 (Incremental Pike Frontend)
> Stdio.File fd = Stdio.File("iim.jpg", "rb");
> Standards.IIM.get_information(fd);
(1) Result: ([ ])
```
Enabling the `werrors` in `decode_photoshop_data()` gives...```
Pike v8.0 release 1783 running Hilfe v3.5 (Incremental Pike Frontend)
> Stdio.File fd = Stdio.File("iim.jpg", "rb");
> Standards.IIM.get_information(fd);
(1) Result: ([ ])
```
Enabling the `werrors` in `decode_photoshop_data()` gives:
```
> Standards.IIM.get_information(fd);
blocks: ({ /* 1 element */
"\4iptc\0\0\0\1\265\34\2\5\0.Britain Scotland Ukraine Nations League Soccer\34\2\n"
"\0\1""5\34\2\17\0\1S\34\2\24\0\bSOC WSOC\34\2""7\0\b20220921\34\2<\0\v152917+0000\34\2P\0\rScott Heppell\34\2U\0\3STR\34\2Z\0\aGlasgow\34\2e\0\3GBR\34\2n\0\2AP\34\2s\0\2AP\34\2t\0""8Copyright 2022 The Associated Press. All rights reserved\34\2x\0\307Ukrainian fans cheer prior to the star of the UEFA Nations League soccer match between Scotland and Ukraine, at Hampden Park, in Glasgow, Scotland, Wednesday, Sept. 21, 2022. (AP Photo/Scott Heppell)\34\2z\0\2HA\0"
})
block: "046970746300000001b51c0205002e4272697461696e2053636f746c616e6420556b7261696e65204e6174696f6e73204c656167756520536f636365721c020a0001351c020f0001531c02140008534f432057534f431c0237000832303232303932311c023c000b3135323931372b303030301c0250000d53636f74742048657070656c6c1c025500035354521c025a0007476c6173676f771c026500034742521c026e000241501c0273000241501c02740038436f70797269676874203230323220546865204173736f6369617465642050726573732e20416c6c207269676874732072657365727665641c027800c7556b7261696e69616e2066616e73206368656572207072696f7220746f207468652073746172206f66207468652055454641204e6174696f6e73204c656167756520736f63636572206d61746368206265747765656e2053636f746c616e6420616e6420556b7261696e652c2061742048616d7064656e205061726b2c20696e20476c6173676f772c2053636f746c616e642c205765646e65736461792c20536570742e2032312c20323032322e202841502050686f746f2f53636f74742048657070656c6c291c027a0002484100"
dsclen: 4
block_length: 1
actual length: 1
info: "\265"
Short info "\265"
(1) Result: ([ ])
```
The cause seems to be that there is an extra byte of NUL-padding after the Photoshop 6.0 header description text ("iptc"). https://www.adobe.com/devnet-apps/photoshop/fileformatashtml/ says that the pascal string should be padded to an even length (ie including the length byte).Pike 8.0https://git.lysator.liu.se/pikelang/pike/-/issues/8055Segmentation fault in backend_find_call_out_info2022-11-06T12:19:26ZPeter BortasSegmentation fault in backend_find_call_out_infoImported from https://youtrack.roxen.com/issue/PIKE-55
Reported by Marcus Wellhardh <wellhard@roxen.com>
Got the following segmentation fault using roxen-6.2.77-test-ep-rhel7_x86_64.sh which in reality is version 6.2.78.
Server versio...Imported from https://youtrack.roxen.com/issue/PIKE-55
Reported by Marcus Wellhardh <wellhard@roxen.com>
Got the following segmentation fault using roxen-6.2.77-test-ep-rhel7_x86_64.sh which in reality is version 6.2.78.
Server version:
```
: Server start command:
: /usr/local/roxen/server-6.2.78/bin/roxen
: -DLOG_GC_TIMESTAMPS
: -DLOG_GC_CYCLES
: -DLOG_GC_HISTOGRAM
: -DREP_DEBUG_DEF_CACHING
: -DRAM_CACHE
: -DHTTP_COMPRESSION
: -M/usr/local/roxen/server-6.2.78/etc/modules
: -M/usr/local/roxen/local/pike_modules
: -I/usr/local/roxen/server-6.2.78/etc/include
: -I/usr/local/roxen/server-6.2.78/base_server
: -P/usr/local/roxen/server-6.2.78/base_server
: -P/usr/local/roxen/server-6.2.78
: base_server/roxenloader.pike
: --pid-file=../configurations/_roxen_pid
```
GDB:
```
(gdb) bt
#0 0x000000000044b2fa in backend_find_call_out_info (me# me@entry
0x8d6758, fun=0x7ffff7e631f0) at /home/dist/tmp/build/pike.srcbuild/../pike/src/backend.cmod:1138
#1 0x000000000044c465 in f_Backend_remove_call_out (args=<optimized out>) at /home/dist/tmp/build/pike.srcbuild/../pike/src/backend.cmod:1289
#2 0x0000000000429fd9 in low_mega_apply (type# APPLY_SVALUE, type@entry
APPLY_SVALUE_STRICT, args# 1, arg1
<optimized out>, arg2# arg2@entry
0x0) at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/apply_low.h:221
#3 0x000000000042a74d in jump_opcode_F_APPLY_AND_POP (arg1=<optimized out>) at /home/dist/tmp/build/pike.srcbuild/../pike/src/interpret_functions.h:2449
#4 0x00007fffe95507d9 in ?? ()
#5 0x00000000011ed2f0 in ?? ()
#6 0x0000000000b28f90 in ?? ()
#7 0x00007ffff0236000 in ?? ()
#8 0x00007ffff7e631c0 in ?? ()
#9 0x0000000000b1e848 in ?? ()
#10 0x00000000008e3820 in ?? ()
#11 0x00007fffeb5fe593 in ?? ()
#12 0x000000000041d636 in eval_instruction (pc=0x7fffeb5fe593 "UH\211\345AWAVAUATSH\203\354\bI\211\377M\213w H\215\005\365\377\377\377I\211F(M\213/I\213VpI\213v`L\211\357H\017\267R\002\307\300\200\371K")
at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:1711
#13 catching_eval_instruction (pc# 0x7fffeb5fe593 "UH\211\345AWAVAUATSH\203\354\bI\211\377M\213w H\215\005\365\377\377\377I\211F(M\213/I\213VpI\213v`L\211\357H\017\267R\002\307\300\200\371K", pc@entry
0x7fffffffd040 "\223\345_\353\377\177")
at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:2754
#14 0x000000000041fc50 in inter_return_opcode_F_CATCH (addr=0x7fffffffd040 "\223\345_\353\377\177") at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:1295
#15 0x00007fffeb5fe57b in ?? ()
#16 0x0000000007245820 in ?? ()
#17 0xfffffffffffffff0 in ?? ()
#18 0x000000005a65d8e6 in ?? ()
#19 0x000000005a65d8e5 in ?? ()
#20 0x0000000000000001 in ?? ()
#21 0x0000000000000001 in ?? ()
#22 0x00000000008d6758 in ?? ()
#23 0x000000000042df96 in eval_instruction (pc=<optimized out>) at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:1711
#24 mega_apply (arg2# 0x0, arg1
0x0, args# args@entry
9320480, type=APPLY_STACK) at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:2695
#25 f_call_function (args# args@entry
9320480) at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:2775
#26 0x000000000044c244 in backend_do_call_outs (me# 0x7ffff7e63180, me@entry
0x8d6758) at /home/dist/tmp/build/pike.srcbuild/../pike/src/backend.cmod:1048
#27 0x000000000044ff39 in pdb_low_backend_once (pdb# 0x8d6740, timeout
timeout@entry=0x7fffffffd4f0) at /home/dist/tmp/build/pike.srcbuild/../pike/src/backend.cmod:4177
#28 0x00000000004501b0 in f_PollDeviceBackend_cq__backtick_28_29 (args=<optimized out>) at /home/dist/tmp/build/pike.srcbuild/../pike/src/backend.cmod:4310
#29 0x0000000000429fd9 in low_mega_apply (type# APPLY_SVALUE, type@entry
APPLY_STACK, args# 1, arg1
<optimized out>, arg1@entry# 0x0, arg2
arg2@entry=0x0) at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/apply_low.h:221
#30 0x000000000042a99e in jump_opcode_F_CALL_FUNCTION_AND_POP () at /home/dist/tmp/build/pike.srcbuild/../pike/src/interpret_functions.h:2452
#31 0x00007ffff000e47c in ?? ()
#32 0x000000000000005f in ?? ()
#33 0x0000000000965ba0 in ?? ()
#34 0x00007ffff0236000 in ?? ()
#35 0x00007ffff7e63120 in ?? ()
#36 0x00000000008caef8 in ?? ()
#37 0x00000000008e3820 in ?? ()
#38 0x00007ffff000c2a4 in ?? ()
#39 0x000000000041d636 in eval_instruction (pc=0x7ffff000c2a4 "UH\211\345AWAVAUATSH\203\354\bI\211\377M\213w H\215\005\365\377\377\377I\211F(M\213/I\213NpH\213I H\213\211\230") at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:1711
#40 catching_eval_instruction (pc# 0x7ffff000c2a4 "UH\211\345AWAVAUATSH\203\354\bI\211\377M\213w H\215\005\365\377\377\377I\211F(M\213/I\213NpH\213I H\213\211\230", pc@entry
0x7ffff7e63240 "") at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:2754
#41 0x000000000041fc50 in inter_return_opcode_F_CATCH (addr=0x7ffff7e63240 "") at /tmp/dist/6.0/pike.rhel7_x86_64/pike/src/interpret.c:1295
#42 0x00007ffff000c28c in ?? ()
#43 0x00007fffffffda14 in ?? ()
#44 0x0000000000000001 in ?? ()
#45 0x00000000005d460d in __dso_handle ()
#46 0x00007fffffffda50 in ?? ()
#47 0x0000000000000000 in ?? ()
(gdb) disassemble 0x000000000044b2fa
Dump of assembler code for function backend_find_call_out_info:
0x000000000044b270 <+0>: push %r12
0x000000000044b272 <+2>: mov 0x403d57(%rip),%rax # 0x84efd0 <Pike_interpreter_pointer>
0x000000000044b279 <+9>: mov %rdi,%r12
0x000000000044b27c <+12>: push %rbp
0x000000000044b27d <+13>: push %rbx
0x000000000044b27e <+14>: mov (%rax),%rbp
0x000000000044b281 <+17>: mov 0x100(%rdi),%eax
0x000000000044b287 <+23>: test %eax,%eax
0x000000000044b289 <+25>: je 0x44b34f <backend_find_call_out_info+223>
0x000000000044b28f <+31>: cmpw $0x8,(%rsi)
0x000000000044b293 <+35>: mov %rsi,%rbx
0x000000000044b296 <+38>: je 0x44b360 <backend_find_call_out_info+240>
0x000000000044b29c <+44>: mov %rbx,%rdi
0x000000000044b29f <+47>: callq 0x540640 <hash_svalue>
0x000000000044b2a4 <+52>: mov 0x114(%r12),%ecx
0x000000000044b2ac <+60>: mov %eax,%esi
0x000000000044b2ae <+62>: xor %edx,%edx
0x000000000044b2b0 <+64>: mov %rsi,%rax
0x000000000044b2b3 <+67>: div %rcx
0x000000000044b2b6 <+70>: shl $0x4,%rdx
0x000000000044b2ba <+74>: add 0x120(%r12),%rdx
0x000000000044b2c2 <+82>: mov 0x8(%rdx),%rcx
0x000000000044b2c6 <+86>: test %rcx,%rcx
0x000000000044b2c9 <+89>: je 0x44b43b <backend_find_call_out_info+459>
0x000000000044b2cf <+95>: mov 0x403cfa(%rip),%r8 # 0x84efd0 <Pike_interpreter_pointer>
0x000000000044b2d6 <+102>: mov (%r8),%rdx
0x000000000044b2d9 <+105>: jmp 0x44b2e9 <backend_find_call_out_info+121>
0x000000000044b2db <+107>: nopl 0x0(%rax,%rax,1)
0x000000000044b2e0 <+112>: mov 0x20(%rcx),%rcx
0x000000000044b2e4 <+116>: test %rcx,%rcx
0x000000000044b2e7 <+119>: je 0x44b34a <backend_find_call_out_info+218>
0x000000000044b2e9 <+121>: cmp %rsi,0x8(%rcx)
0x000000000044b2ed <+125>: jne 0x44b2e0 <backend_find_call_out_info+112>
0x000000000044b2ef <+127>: mov 0x40(%rcx),%rax
0x000000000044b2f3 <+131>: lea 0x10(%rdx),%rdi
0x000000000044b2f7 <+135>: mov %rdi,(%r8)
=> 0x000000000044b2fa <+138>: addl $0x1,(%rax)
0x000000000044b2fd <+141>: movq $0x8,(%rdx)
0x000000000044b304 <+148>: mov %rax,0x8(%rdx)
0x000000000044b308 <+152>: mov %rdi,%rdx
0x000000000044b30b <+155>: jmp 0x44b2e0 <backend_find_call_out_info+112>
0x000000000044b30d <+157>: nopl (%rax)
0x000000000044b310 <+160>: mov -0x8(%rdx),%r12
0x000000000044b314 <+164>: mov %rbx,%rdi
0x000000000044b317 <+167>: mov 0x28(%r12),%rsi
0x000000000044b31c <+172>: callq 0x541370 <is_eq>
0x000000000044b321 <+177>: test %eax,%eax
0x000000000044b323 <+179>: jne 0x44b3b0 <backend_find_call_out_info+320>
0x000000000044b329 <+185>: mov 0x403ca0(%rip),%rax # 0x84efd0 <Pike_interpreter_pointer>
0x000000000044b330 <+192>: mov (%rax),%rcx
0x000000000044b333 <+195>: lea -0x10(%rcx),%rdx
0x000000000044b337 <+199>: mov %rdx,(%rax)
0x000000000044b33a <+202>: movzwl -0x10(%rcx),%eax
0x000000000044b33e <+206>: and $0xfffffff8,%eax
0x000000000044b341 <+209>: cmp $0x8,%eax
0x000000000044b344 <+212>: je 0x44b420 <backend_find_call_out_info+432>
0x000000000044b34a <+218>: cmp %rdx,%rbp
0x000000000044b34d <+221>: jb 0x44b310 <backend_find_call_out_info+160>
0x000000000044b34f <+223>: xor %eax,%eax
0x000000000044b351 <+225>: pop %rbx
0x000000000044b352 <+226>: pop %rbp
0x000000000044b353 <+227>: pop %r12
0x000000000044b355 <+229>: retq
0x000000000044b356 <+230>: nopw %cs:0x0(%rax,%rax,1)
---Type <return> to continue, or q <return> to quit---
(gdb) info reg
rax 0x0 0
rbx 0x7ffff7e631f0 140737352446448
rcx 0x14ef0a80 351210112
rdx 0x7ffff7e63200 140737352446464
rsi 0x459954 4561236
rdi 0x7ffff7e63210 140737352446480
rbp 0x7ffff7e63200 0x7ffff7e63200
rsp 0x7fffffffcec0 0x7fffffffcec0
r8 0x8e3820 9320480
r9 0x186a0 100000
r10 0x8e3820 9320480
r11 0x293 659
r12 0x8d6758 9267032
r13 0x7ffff7e631f0 140737352446448
r14 0x8e3380 9319296
r15 0xb1c5c8 11650504
rip 0x44b2fa 0x44b2fa <backend_find_call_out_info+138>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb)
```