#700 Ticket #698 not solved in EPIC 0.7.5

[Mike]

the issue still occurs. Is it possible that the fix has not been rolled out?

Message:
recv() is deprecated on :utf8 handles. This will be a fatal error in Perl 5.30
at D:/strawberry64/perl/lib/IO/Socket.pm line 304 (#1)
(D deprecated) The sysread(), recv(), syswrite() and send() operators are
deprecated on handles that have the :utf8 layer, either explicitly, or
implicitly, eg., with the :encoding(UTF-16LE) layer.

Using strawberry perl.
This is perl 5, version 26, subversion 1 (v5.26.1) built for MSWin32-x64-multi-thread

[Mike]

An IOException occurred while executing debugger command
could not match re.IP_POS in {recv() is deprecated on :utf8 handles. This will be a fatal error in Perl 5.30 at D:/strawberry64/perl/lib/IO/Socket.pm line 304.
at D:/strawberry64/perl/lib/IO/Socket.pm line 304.
IO::Socket::recv(IO::Socket::INET=GLOB(0x5361980), "", 2048) called at D:/Eclipse/ws-pos/.metadata/.plugins/org.epic.debug/perl5db.pl line 7358
DB::readline(" DB<23> ") called at D:/Eclipse/ws-pos/.metadata/.plugins/org.epic.debug/perl5db.pl line 1858
DB::_DB__read_next_cmd(undef) called at D:/Eclipse/ws-pos/.metadata/.plugins/org.epic.debug/perl5db.pl line 2786
DB::DB called at

[Jan Ploski]

I checked that the change has been rolled out in 0.7.5.

What you can do is look in $WORKSPACE/.metadata/.plugins/org.epic.debug/ which is where EPIC writes its helper modules upon every launch (including perl5db.pl, which is a patched version of the Perl debugger, and dumpvar_epic.pm, which is where the particular fix for 0.7.5 got applied - https://github.com/jploski/epic-ide/commit/17579c6e289a6f7d57815efbd1f84c9a016cf16d). You can copy these helper modules from there to another directory (to avoid them being overwritten) and then put that directory into your project's include path (via project properties), which will make your versions take precedence over EPIC's ones. Then you can tweak the modules so as to achieve a working fix (and report back what exactly was needed in your case).

[Nuno Furbiz]

Hi Jan,

First, thank you for the work you have done. I appreciate it.

I have this problem too. I tried your suggestion above - created a copy of the two files in another folder which I added to the EPIC path list. It doesn't seem to use my copies.
I amnot sure which process/exe actually calls the dumpvar_epic.pm module - perl.exe or the org.eclipse..jar file?

I looked at the change you made to the source, read up what I could about the "binmode" command, "Perl::IO" encode, and the utf8 issue.

Before I continue, please forgive my ignorance as I am only just starting to attain the status of 'noob' amongst 'script-kiddies'... 8-|

...but, I wondered if any of these would make a difference in dumpvar_epic.pm:

CURRENT:
binmode($DB::OUT, ":utf8");
OPTION1:
binmode($DB::OUT, ":raw:utf8"); # after I read up on Perl::IO
OPTION2:
use Perl::IO;
binmode($DB::OUT, ":encoding(UTF-8)"); # as above

Sorry if I totally mis-understood this....

Also, I observed the following - I have a script with these two lines:
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime();
my $datestamp = sprintf("%04d%02d%02d", $year+1900, $mon+1, $mday);

When I press [F11] to debug, it gets as far as the first line - I can see all the date/time variables in the debug variables window and the values they hold at that instant.
The error we have seen is triggerred on the second line above - could there be something about the format string in the sprintf() command that causes (or is at least symptomatic of) it?

Again, THANK YOU ALL who have developed this!!!
:)

[Nuno Furbiz]

I just found these two link - I consider these authoritative.

Could this lead us to the answer?

From the Perly Gates:
http://www.perlmonks.org/?node_id=1195588
And Mr Ed ('The Horse'):
https://rt.perl.org/Public/Bug/Display.html?id=125760

(...forgive me if those references are too obtuse :) )

[Nuno Furbiz]

I think I fixed it, but I need someone who understands to verify it....

The second thread above (perl.org) documents the discussion and implementation of the exception we are seeing in the EPIC debugger (below).
BTW, looking more closely at the exception message:
--- BEGIN ---
recv() is deprecated on :utf8 handles. This will be a fatal error in Perl 5.30 a
t C:/Perl64/lib/IO/Socket.pm line 304.
at C:/Perl64/lib/IO/Socket.pm line 304.
IO::Socket::recv(IO::Socket::INET=GLOB(0x323f250), "", 2048) called at C:/Users
/%USERNAME%/eclipse-workspace/fixes/perl5db.pl line 7358
--- END ---
Sorry Jan, your suggestion did work! It is using my copy.

So here is what I have just changed and it is now working for me:
dumpvar_epic.pm: LINE 123:
CHANGED -> 'binmode($DB::OUT, ':utf8'); ' -> TO -> 'binmode($DB::OUT, ':raw'); '

However, I really do not know what I am doing so I would be very grateful if someone who does could review this and advise on the full ramifications of changing 'utf8' to 'raw' in the binmode command...

Thank you :)

[Dave Wilbur]

Thank you guys for this thread. I just got an upgraded machine at work and started to get this error after installing the latest Eclipse/EPIC. I have found that either
binmode($DB::OUT, ':raw');
or
binmode($DB::OUT, ':encoding(UTF-8)');
on line 123 of the new dumpvarepic.pm avoid the fatal warning while using the variables debug window to watch my variables. I'm not sure if the raw layer does anything different than standard binmode without specifying a layer. Based on what I've read in the various discussions, it seems to me (not that experienced) that the ':raw' makes more sense for this usage. That is what I am going to use until I see some quirky behavior and then I will try the ':encoding(UTF-8)' to see if that fixes it. Again, Stephen and Jan, thanks for this info!

[Nuno Furbiz]

I'm very pleased to know it has helped you :)

Steve

On Thu, 30 Aug 2018 at 07:05, Dave Wilbur dvwilbur@users.sourceforge.net
wrote:

Thank you guys for this thread. I just got an upgraded machine at work and
started to get this error after installing the latest Eclipse/EPIC. I have
found that either
binmode($DB::OUT, ':raw');
or
binmode($DB::OUT, ':encoding(UTF-8)');
on line 123 of the new dumpvarepic.pm http://dumpvarepic.pm avoid the
fatal warning while using the variables debug window to watch my variables.
I'm not sure if the raw layer does anything different than standard binmode
without specifying a layer. Based on what I've read in the various
discussions, it seems to me (not that experienced) that the ':raw' makes
more sense for this usage. That is what I am going to use until I see some
quirky behavior and then I will try the ':encoding(UTF-8)' to see if that
fixes it. Again, Stephen and Jan, thanks for this info!

---

• [bugs:#700] https://sourceforge.net/p/e-p-i-c/bugs/700/ Ticket #698
  not solved in EPIC 0.7.5*

Status: open
Group: v0.7.x
Created: Thu May 17, 2018 08:19 PM UTC by Mike
Last Updated: Fri Aug 17, 2018 03:10 PM UTC
Owner: nobody

the issue still occurs. Is it possible that the fix has not been rolled
out?

Message:
recv() is deprecated on :utf8 handles. This will be a fatal error in Perl
5.30
at D:/strawberry64/perl/lib/IO/Socket.pm line 304 (#1)
(D deprecated) The sysread(), recv(), syswrite() and send() operators are
deprecated on handles that have the :utf8 layer, either explicitly, or
implicitly, eg., with the :encoding(UTF-16LE) layer.

Using strawberry perl.
This is perl 5, version 26, subversion 1 (v5.26.1) built for
MSWin32-x64-multi-thread

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/e-p-i-c/bugs/700/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Liang Xu]

Thank you Jan and Steve, I also got the issue fixed with your solution. Hope this issue would be fixed permanently in the future.

[Nuno Furbiz]

I'm glad it has helped you :)
Steve

On Tue, 11 Sep 2018 at 12:54, Liang Xu mosxl@users.sourceforge.net wrote:

Thank you Jan and Steve, I also got the issue fixed with your solution.
Hope this issue would be fixed permanently in the future.

---

• [bugs:#700] https://sourceforge.net/p/e-p-i-c/bugs/700/ Ticket #698
  not solved in EPIC 0.7.5*

Status: open
Group: v0.7.x
Created: Thu May 17, 2018 08:19 PM UTC by Mike
Last Updated: Wed Aug 29, 2018 09:05 PM UTC
Owner: nobody

the issue still occurs. Is it possible that the fix has not been rolled
out?

Message:
recv() is deprecated on :utf8 handles. This will be a fatal error in Perl
5.30
at D:/strawberry64/perl/lib/IO/Socket.pm line 304 (#1)
(D deprecated) The sysread(), recv(), syswrite() and send() operators are
deprecated on handles that have the :utf8 layer, either explicitly, or
implicitly, eg., with the :encoding(UTF-16LE) layer.

Using strawberry perl.
This is perl 5, version 26, subversion 1 (v5.26.1) built for
MSWin32-x64-multi-thread

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/e-p-i-c/bugs/700/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[Martin Boyer]

Dave,
Thanks for the fix. I also had problems with EPIC 0.7.5, which were fixed by:
1. editing line 123 of the 0.7.5 version dumpvarepic.pm as "binmode($DB::OUT, ':encoding(UTF-8)');"
2. putting this copy of dumpvarepic.pm in a directory outside the Eclipse workspace
3. adding this directory to the list of directories in the "Perl Include Path" properties of the relevant Eclipse project

Just to be clear, upgrading to EPIC 0.7.5 alone didn't fix my problem. This is on Eclipse Photon (4.8).

[Jan Ploski]

I added this fix - binmode($DB::OUT, ':encoding(UTF-8)') rather than binmode($DB::OUT, ':utf-8') to EPIC 0.7.6 now. The automated tests seem to be still working.

Can you test if this new version installs and works ok for you? Note that EPIC 0.7.6 now requires at least Java SE 7 to execute (so don't upgrade if you must stay with Java SE 6.0).

[Martin Boyer]

Jan,
EPIC 0.7.6 seems to work for me. Thanks!
Environment:
Windows 10
ActivePerl 5.26.1
Java 1.8
Eclipse Photon (4.8)
EPIC 0.7.6
No customized version of dumpvar_epic.pm

[tschoening]

I added this fix - binmode($DB::OUT, ':encoding(UTF-8)') rather than binmode($DB::OUT, ':utf-8') to EPIC 0.7.6 now.

Please have a look at the original bug ticket and patches again, in my opinion it makes very clear that using ":encoding(...)" is deprecated as well:

+(W deprecated) The sysread(), recv(), syswrite() and send() operators
+are deprecated on handles that have the C<:utf8> layer, either
+explicitly, or implicitly, eg., with the C<:encoding(UTF-16LE)> layer.

https://rt.perl.org/Public/Ticket/Attachment/1360169/728149/0001-perl-125760-deprecate-sys-read-write-send-recv-on-ut.patch

+Note that if the filehandle has been marked as C<:utf8>, C<sysread> will
+throw an exception. The C<:encoding(...)> layer implicitly
introduces the C<:utf8> layer.</sysread>

https://rt.perl.org/Public/Ticket/Attachment/1583747/827814/0001-perl-133170-fatalize-sysread-syswrite-recv-send-on-u.patch

I have the feeling the current patches only check the ":utf-8"-flag directly, so it might be possible to trick the warnings with your approach. But it seems still wrong. Have a look at how the official tests are changed:

 foreach my $operator ('print', 'syswrite', 'syswrite len', 'syswrite off',
              'syswrite len off') {
-    foreach my $layer ('', ':utf8') {
-   open my $fh, "+>$layer", $tmpfile or die $!;
+    foreach my $layer ('', $operator =~ /syswrite/ ? () : (':utf8')) {
+   open my $fh, "+>:raw$layer", $tmpfile or die $!;
    my $pad = $operator =~ /\boff\b/ ? "\243" : "";
    my $trail = $operator =~ /\blen\b/ ? "!" : "";
    my $u = UTF8Toggle->new("$pad$E_acute\n$trail");

https://rt.perl.org/Public/Ticket/Attachment/1583747/827814/0001-perl-133170-fatalize-sysread-syswrite-recv-send-on-u.patch

In case of syswrite, only ":raw" is used, no ":utf8" at all. That is the only correct fix in my opinion, using ":raw" and encoding/decoding later:

https://sourceforge.net/p/e-p-i-c/bugs/700/#5762/75b5/9568/137e/3a76/4f69/aa47
https://rt.perl.org/Ticket/Display.html?id=125760

[Jan Ploski]

Ok, I changed the code in 0.7.7 to rely on :raw and on the Encode module.

I also discovered and hopefully fixed more bugs with transfer of non-ASCII values or variable names from perldb into the "Variables" view and another one with signalling truncation of large (>64K) values...

[Martin Boyer]

EPIC 0.7.7 seems to work for me.
Environment:
Windows 10
ActivePerl 5.26.1
Java 1.8
Eclipse Photon (4.8)
EPIC 0.7.7

[Jan Ploski]

dumpvar_epic.pm is picked via @INC (Perl include path) by the command "do" in dump_local_vars.pl and dump_global_vars.pl scripts (see https://github.com/jploski/epic-ide/tree/testing/org.epic.debug). The code of those two scripts, extracted from the plugins/org.epic.debug_x.y.z.jar archive found in your Eclipse install directory, is passed inline (with some context-related substitutions) through the STDIN stream to the Perl debugger process. So the answer is, perl.exe, which is running perl5db.pl, executes dumpvar_epic.pm on behalf of Eclipse.

If you set the option "Preferences > Perl > Enable debugger console (experimental)", you will be able to view all communications between the Eclipse process and the Perl debugger process through the Console view. To make Console view show this content, click on "perl -d" item in the Debug view displaying the program being debugged.

Furthermore, with this same option, the entire command line of how the Perl debugger is started by EPIC will be written to Eclipse error log (which you can either see in the Error Log view, or if that view is missing in your Eclipse installation, by looking into the file $WORKSPACE/.metadata/.log directly).

If the include path tweaks supposed to override the default version of dumpvar_epic.pm don't work for you for whatever reason, you could also exchange the dumpvar_epic.pm source in the org.epic.debug.x.y.z.jar archive, from which it is extracted every time you launch the debugger. (It's a zip file.)

For debugging of dumpvar_epic.pm behavior, I recommend that you add to it something like { open(FL, '>>c:/windows/temp/log.txt'); print FL "testing testing\n"; close(FL); } because the STDOUT/STDERR are likely redirected and would break something if you used them.

This problem is most likely not related to sprintf.

[Nuno Furbiz]

Again, thank you Jan.

I have the (experimental) debugger console enabled....now I know which checkbox turned it on! Thanks.

I figured perl.exe was executing .pl/.pm...I didn't realise that 'dumpvar_epic.pm' was 'compiled' into the org.epic.debug_x.y.z.jar.

I have dumpvar_epic.pm open in Notepad++ and I noticed just now as I was debugging my script that it reloaded after being changed on disk, but it is not my copy that changed....it is the normal copy under the ./org.epic.debug/...folder.

So, it seems that even if a path setting causes a default file/module to be overridden, eclipse will still extract and write the default copy even though it will not get used...
Right?

[Jan Ploski]

Yes, the extraction always happens on every launch. But by prepending another directory to @INC path you are tricking the Perl interpreter into not using what EPIC would normally want it to use.

As for your fix, I'll test it, but I suspect that changing from :utf8 to :raw might have unwanted side effects of not being able to see UTF-8 characters contained in variable values (maybe also in variable names in source code). If you want to test yourself, try "use utf8;" and add some variables with such characters to your script and watch if the "Variables" view still displays them correctly.

[tschoening]

As for your fix, I'll test it, but I suspect that changing from :utf8 to :raw might have unwanted side effects of not being able to see UTF-8 characters[...]

+1, changing to ":raw" alone doesn't make much sense if one explicitly worked with UTF-8 characters before. Using ":raw" in combination with explicitly encoding/decoding to/from UTF-8 before writing/after reading OTOH should be the proper solution. I often prefer "Encode::Ecode|decode" instead of "utf8::encode|decode", because it croaks on invalid data.

Encode::decode('UTF-8', $buffer, Encode::FB_CROAK()[ | Encode::LEAVE_SRC()])

Depending on where $DB::OUT comes from and what it is, it might be easier to handle things there instead of all individual "print"-statements?