Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 2 months ago.
Improve this question
I am trying to test out the new version of cpan-Net-DNS (version 1.35) and it fails in the Net/DNS/Resolver/Base.pm file at line 987 with the following error.
*** FATAL PROGRAM ERROR!! Unknown instance method 'size'
*** which the program has attempted to call for the object:
***
. IN OPT ; no data
***
*** THIS IS A BUG IN THE CALLING SOFTWARE, which incorrectly assumes
*** that the object would be of a particular type. The type of an
*** object should be checked before calling any of its methods.
***
Net::DNS::RR 1714 at Net/DNS/Resolver/Base.pm line 987.
Net::DNS::Resolver::Base::_make_query_packet(Net::DNS::Resolver=HASH(0x55ebcfcd3d68), "example.com") called at Net/DNS/Resolver/Base.pm line 402
Net::DNS::Resolver::Base::send(Net::DNS::Resolver=HASH(0x55ebcfcd3d68), "example.com") called at Net/DNS/Resolver/Base.pm line 374
Has anyone seen this before?
This was on linux version 5.15. I tried the same thing on linux version 5.10 and it works but I can't pin point as to why. Here is the snippet of code I am running. This is on perl5.26
use Test::Simple;
use Net::DNS;
my $resolver = new Net::DNS::Resolver();
my $packet = $resolver->query('example.com');
ok($packet->answersize > 0, "NET::DNS");
Related
Facing below issue when execute catalyst server script.
Couldn't load class (Catalyst::Script::Server) because: "ensure_class_loaded" is not exported by the Catalyst::Utils module
Can't continue after import errors at /opt/madhan/lib/perl5/Catalyst/ScriptRole.pm line 7.
BEGIN failed--compilation aborted at /opt/madhan/lib/perl5/Catalyst/ScriptRole.pm line 7.
Compilation failed in require at /usr/lib/perl5/site_perl/5.8.8/Module/Runtime.pm line 313.
Compilation failed in require at /opt/madhan/lib/perl5/Catalyst/ScriptRunner.pm line 13.
Catalyst::ScriptRunner::find_script_class("Catalyst::ScriptRunner", "testsite", "Server") called at /opt/madhan/lib/perl5/Catalyst/ScriptRunner.pm line 42
Catalyst::ScriptRunner::run("Catalyst::ScriptRunner", "testsite", "Server") called at /opt/madhan/testsite/script/testsite_server.pl line 8
Will the perl 5.8.8 support Catalyst MVC?
This is a bug in Catalyst. There was some type-checking code in Catalyst::ScriptRole (since 2012!) which was completely broken, but the brokenness was only visible in particular circumstances — namely, if a script provided a loader_class to Catalyst::ScriptRole that wasn't already a loaded class (likely no one ever has), or if the system has a very old version of UNIVERSAL.pm such as that shipped with perl 5.8. It's this second case that you're running into.
I've pushed a patch to Catalyst-Runtime to resolve this problem; hopefully it will be released soon it's included in Catalyst-Runtime 5.90115.
Is there any way to interpret the hex address directly/indirectly in fortran(90). For instance, some times I get memory segmentation issue followed by Failing at address: 0x1fffffff8. A more complete message is something like this:
[amir-desktop] *** Process received signal ***
[amir-desktop] Signal: Segmentation fault (11)
[amir-desktop] Signal code: Address not mapped (1)
[amir-desktop] Failing at address: 0x1fffffff8
[amir-desktop] [ 0] /lib/libpthread.so.0(+0xf8f0) [0x2af5efcb08f0]
[amir-desktop] [ 1] test.exe(__box_mod_MOD_constructlist+0x35c) [0x44052c]
[amir-desktop] [ 2] test.exe(__box_mod_MOD_box_move+0x72) [0x443372]
[amir-desktop] [ 3] test.exe() [0x44c81b]
[amir-desktop] [ 4] test.exe(main+0x1d) [0x41336d]
[amir-desktop] [ 5] /lib/libc.so.6(__libc_start_main+0xfd) [0x2af5f59a9c8d]
[amir-desktop] [ 6] test.exe() [0x41391d]
Is it possible to realize that this address is related to a specific variable, maybe by a simple print statement. I know that loc function prints an integer regarding the address of the variable (Another question arise if they are convertible to hex type address). I would guess that it might be possible to use debugger for that purpose. I would appreciate if some one can comment on this (and some suggestion) as well.
I am currently using gfortran 4.6. under linux distribution.
Thanks
This line:
[amir-desktop] [ 1] test.exe(__box_mod_MOD_constructlist+0x35c) [0x44052c]
tells you that the error was in the function constructlist in the box_mod module. I would start looking there for any obvious errors first.
Try compiling with the following flags:
gfortran -g -fbacktrace -fbounds-check -Wall test.f90
These will (in order): turn on debugging symbols, print out backtraces, check array bounds and print most warnings about unsafe code during compilation.
If that still doesn't solve your problem, you can use gdb on a core dump. This is a record of the state of your program when it crashed. You'll need to enable core dumps first by running ulimit -c unlimited in your terminal. Next, run your code - you should get an error like Segmentation fault (core dumped) - and it will create a file named core or core.pid, where pid is a number. Finally, you can run gdb like so:
gdb ./test.exe core.pid
It will print a whole bunch of information and then leave you with a (gdb) prompt. Run a stack trace with bt to see what happened when your program crashed. quit will exit gdb.
I am using lua 5.1 in a linux system.I installed the luasocket 2.0.2 using this manual.But when i execute the below code of the file test.lua
socket = require("socket")
print(socket._VERSION)
I get the following errors :
lua: ./usr/local/share/lua/5.1/socket.lua:14: loop or previous error loading module 'socket'
stack traceback:
[C]: in function 'require'
./usr/local/share/lua/5.1/socket.lua:14: in main chunk
[C]: in function 'require'
test.lua:1: in main chunk
[C]: ?
But i have included the environmental variable as below:
LUA_PATH=/usr/local/share/lua/5.1/?.lua;?.lua
LUA_CPATH=/usr/local/lib/lua/5.1/?.so;?.so
You usually get this error when you have a loop in your require calls, for example, when you do require "socket" and from that module you do require "socket" again, before the first require call is finished.
Check line 14 in socket.lua file. It should probably have something like local socket = require("socket.core") (and not require("socket")). To check if the issue is with loading socket.core, try executing require "socket.core" in your own script as it may give you a better error message.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
i just installed munin-node on my new cent os 5.7 64bit machine via yum.
Installation went fine, i've setup munin and munin-nodes on many machines in the past, but this time i cannot get it to start.
When I try to restart it with the following command this happens:
[root#Server2 munin]# service munin-node restart
Stopping Munin Node agents: kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]
[FAILED]
Starting Munin Node: Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/vendor_perl/5.8.8/Net/Server/Daemonize.pm line 61.
Couldn't find pid in existing pid_file at /usr/lib/perl5/vendor_perl/5.8.8/Net/Server/Daemonize.pm line 61.
[ OK ]
It says [OK] in the end in green, but I don't see it running anywhere.
Also this is the output of munin-node.log
[root#Server2 munin]# tail -n 100 munin-node.log
2011/12/04-03:10:44 Couldn't find pid in existing pid_file at /usr/lib/perl5/vendor_perl/5.8.8/Net/Server/Daemonize.pm line 61.
at line 276 in file /usr/lib/perl5/vendor_perl/5.8.8/Net/Server.pm
2011/12/04-03:10:44 Server closing!
2011/12/04-03:10:54 Couldn't find pid in existing pid_file at /usr/lib/perl5/vendor_perl/5.8.8/Net/Server/Daemonize.pm line 61.
at line 276 in file /usr/lib/perl5/vendor_perl/5.8.8/Net/Server.pm
2011/12/04-03:10:54 Server closing!
Ive looked up line 61 in Daemonize.pm and it is:
my $current_pid = $_current_pid =~ /^(\d{1,10})/ ? $1 : die "Couldn't find pid in existing pid_file";
I've tried to rename the pid file in /etc/munin/munin-node.conf but that also didnt change anything.
Output of:
[root#Server2 plugins]# sudo /usr/sbin/munin-node-configure --suggest
http://pastebin.com/Yd6eX5Ss which seems all perfect to me.
Any idea what I can try?
Removing the original PID file fixed the problem.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I want to configure my new PostgreSQL Server without ldap. When I execute "gmake world" command it turns out the follwoing error; anybody knows this?
If have tested that if I configure PostgreSQL --with-ldap, it is okay!
--version
PostgreSQL: Postgresql 9.1
OS : Red Hat Enterprise Linux Server release 5.5 (Tikanga)
--config script
./configure --prefix=/opt/pgsql9.1 --with-pgport=1923 --with-segsize=8 --with-wal-segsize=64 --with-wal-blocksize=64 --with-perl --with-python --with-openssl --with-pam --with-libxml --with-libxslt --enable-thread-safety --without-ldap
--a part of "gmake world" log
utils/time/tqual.o utils/time/snapmgr.o utils/fmgrtab.o ../../src/timezone/localtime.o ../../src/timezone/strftime.o ../../src/timezone/pgtz.o ../../src/port/libpgport_srv.a -lxslt -lxml2 -lpam -lssl -lcrypto -lcrypt -ldl -lm -o postgres
libpq/auth.o: In function `InitializeLDAPConnection':
auth.c:(.text+0x2c4): undefined reference to `ldap_init'
auth.c:(.text+0x2e7): undefined reference to `ldap_set_option'
auth.c:(.text+0x329): undefined reference to `ldap_start_tls_s'
auth.c:(.text+0x339): undefined reference to `ldap_unbind'
auth.c:(.text+0x37e): undefined reference to `ldap_unbind'
libpq/auth.o: In function `CheckLDAPAuth':
auth.c:(.text+0x163a): undefined reference to `ldap_simple_bind_s'
auth.c:(.text+0x1647): undefined reference to `ldap_unbind'
auth.c:(.text+0x1690): undefined reference to `ldap_simple_bind_s'
auth.c:(.text+0x174c): undefined reference to `ldap_search_s'
auth.c:(.text+0x1768): undefined reference to `ldap_count_entries'
auth.c:(.text+0x1783): undefined reference to `ldap_first_entry'
auth.c:(.text+0x1792): undefined reference to `ldap_get_dn'
auth.c:(.text+0x17c3): undefined reference to `ldap_memfree'
auth.c:(.text+0x17ce): undefined reference to `ldap_msgfree'
auth.c:(.text+0x17d9): undefined reference to `ldap_unbind_s'
auth.c:(.text+0x1929): undefined reference to `ldap_get_option'
auth.c:(.text+0x1964): undefined reference to `ldap_err2string'
auth.c:(.text+0x19c2): undefined reference to `ldap_get_option'
auth.c:(.text+0x19fd): undefined reference to `ldap_err2string'
auth.c:(.text+0x1a42): undefined reference to `ldap_msgfree'
auth.c:(.text+0x1a5e): undefined reference to `ldap_count_entries'
auth.c:(.text+0x1b0a): undefined reference to `ldap_count_entries'
collect2: ld 返回 1
gmake[2]: *** [postgres] 错误 1
gmake[2]: Leaving directory `/opt/soft_bak/postgresql-9.1.0/src/backend'
gmake[1]: *** [all-backend-recurse] 错误 2
gmake[1]: Leaving directory `/opt/soft_bak/postgresql-9.1.0/src'
gmake: *** [world-src-recurse] 错误 2
If you first build --with-ldap and then without, you need to run make distclean in between (or do configure --enable-depend in the first run).