[#11890] Ruby and Solaris door library — "Hiro Asari" <asari.ruby@...>

Hi, there. This is my first patch against ruby. I think I followed

19 messages 2007/08/13
[#11892] Re: Ruby and Solaris door library — Daniel Berger <djberg96@...> 2007/08/14

Hiro Asari wrote:

[#11899] pack/unpack 64bit Integers — Hadmut Danisch <hadmut@...>

Hi,

13 messages 2007/08/14
[#11903] Re: pack/unpack 64bit Integers — Brian Candler <B.Candler@...> 2007/08/15

On Wed, Aug 15, 2007 at 06:50:01AM +0900, Hadmut Danisch wrote:

[#11948] Fibers in Ruby 1.9? — David Flanagan <david@...>

I just noticed that my ruby1.9 build of August 17th includes a Fiber

22 messages 2007/08/22
[#11949] Re: Fibers in Ruby 1.9? — Daniel Berger <djberg96@...> 2007/08/22

David Flanagan wrote:

[#11950] Re: Fibers in Ruby 1.9? — "Francis Cianfrocca" <garbagecat10@...> 2007/08/22

On 8/22/07, Daniel Berger <djberg96@gmail.com> wrote:

[#11952] Re: Fibers in Ruby 1.9? — MenTaLguY <mental@...> 2007/08/22

On Wed, 22 Aug 2007 20:50:12 +0900, "Francis Cianfrocca" <garbagecat10@gmail.com> wrote:

[#11988] String#length not working properly in Ruby 1.9 — "Vincent Isambart" <vincent.isambart@...>

I saw that Matz just merged his M17N implementation in the trunk.

17 messages 2007/08/25
[#11991] Re: String#length not working properly in Ruby 1.9 — "Michael Neumann" <mneumann@...> 2007/08/25

On Sat, 25 Aug 2007 10:54:20 +0200, Yukihiro Matsumoto

[#11992] Re: String#length not working properly in Ruby 1.9 — Yukihiro Matsumoto <matz@...> 2007/08/25

Hi,

[#12042] Encodings of string literals; explicit codepoint escapes? — David Flanagan <david@...>

This message contains queries that probably only Matz can answer:

16 messages 2007/08/31
[#12043] Re: Encodings of string literals; explicit codepoint escapes? — Yukihiro Matsumoto <matz@...> 2007/08/31

Hi,

Core dump with simple web scraper when run via cron

From: Daniel Berger <Daniel.Berger@...>
Date: 2007-08-10 14:15:39 UTC
List: ruby-core #11886
Hi all,

Solaris 10
Sun Studio Compiler 12
ruby 1.8.6 (2007-08-07 patchlevel 5000) [sparc-solaris2.10]
mechanize 0.6.10
rubygems 0.9.4

$CC => cc
$CFLAGS => -g -dalign -fns -xbuiltin=%all -xlibmil -xtarget=ultra2e -xO5 
-xipo -xarch=sparc

I'm hitting a core dump with the following program. It works fine when I 
run it from the command line, but when run via cron it dumps core. 
Here's the program in its entirety:

# rf_downloads.rb
#!/usr/local/bin/ruby
require 'rubygems'
require 'mechanize'

agent = WWW::Mechanize.new
body = agent.get('http://rubyforge.org/top/toplist.php?type=downloads').body

regex = /<a href="\/projects\/\w+?\/">(.*?)<\/a>.*?(\d+)/
file  = "Rubyforge_Downloads_" + Time.now.strftime("%d_%b_%Y")
fh    = File.open(file, 'w')

body.split("\n").each{ |line|
    if m = regex.match(line)
       project   = m.captures[0].ljust(40)
       downloads = m.captures[1]
       fh.puts "#{project} #{downloads}"
    end
}

fh.close
# end rf_downloads.rb

Here's the stack info.

djberge-/export/home/djberge/cronjobs-554>mdb /usr/local/bin/ruby core
Loading modules: [ libc.so.1 ld.so.1 ]
 > ::status
debugging core file of rf_downloads.rb (32-bit) from unknown
file: /usr/local/bin/ruby
initial argv: /usr/local/bin/ruby 
/export/home/djberge/cronjobs/rf_downloads.rb
threading model: multi-threaded
status: process terminated by SIGABRT (Abort)
 > ::stack
libc.so.1`_lwp_kill+8(6, 0, ff1ee450, ff1a4d94, ffffffff, 6)
libc.so.1`abort+0x110(2e, 1, 1531c4, aa1a0, ff1ed2d8, 0)
rb_bug+0xc8(137800, 137800, 164bd0, 142c00, 164800, 164800)
libc.so.1`__sighndlr+0xc(b, 0, ffbd2160, e91c4, 0, 1)
libc.so.1`call_user_handler+0x3b8(b, 0, 0, 0, ff0f2000, ffbd2160)
libc_psr.so.1`memcpy+0x1210(a1a700, ffc00030, 14, 0, 30, 9ecb70)
rb_thread_save_context+0x1c8(1ad8f0, 0, 9ecb70, 165000, b6f7, b6f7)
rb_thread_start_0+0xd0(73578, 96ac20, 6a6f60, 0, 64c00, 73400)
rb_call0+0x80c(19b078, 19b090, 13c1, 13c1, 0, 0)
rb_call+0x404(19b090, f31, 0, 156000, 19afe8, 19b078)
rb_eval+0x1fe0(21fbd0, 220fc8, ffbd8af0, 1a0583f, 340b, ffbd5154)
rb_eval+0xe48(21fbd0, 220db8, 19, 164800, 165000, 156000)
rb_eval+0x3118(21fbd0, 220d88, 0, 156000, 0, 2f)
rb_eval+0x1498(21fbd0, 2210d0, 21fb70, 156000, 2, 164800)
rb_call0+0x10d8(1, ffbd8ac4, 4, 1, 221328, 0)
rb_call+0x404(21fbd0, f31, 2, 156000, 21fb28, 21fae0)
rb_eval+0x1fe0(96bc10, 2206f8, 96ac98, 96ac98, 98, 3)
block_pass+0x198(156000, 220710, 49, 164800, 220710, 156000)
rb_eval+0xc10(96bc10, 2207d0, 1, 156000, 220800, 2)
rb_call0+0x10d8(1, ffbdbfc4, 220830, 4, 220800, 0)
rb_call+0x404(96bc10, f31, 1, 156000, 21fba0, 1)
rb_eval+0x2354(96bc10, 229ab8, ffbdf160, 430583f, 860b, ffbde264)
rb_eval+0xe48(96bc10, 229938, 0, 156000, 229b18, 2f)
rb_call0+0x10d8(0, ffbdf134, 229938, 0, 229b18, 0)
rb_call+0x404(96bc10, f31, 0, 156000, 21f3c0, 2)
rb_eval+0x2388(96bc10, 22a2c8, 0, 156000, 22a298, 22a298)
rb_eval+0xb8c(96bc10, 22a160, 0, 4, 96aed8, ffbe2708)
rb_eval+0x12cc(96bc10, 229ed8, 1, 156000, 22a3b8, 2)
rb_call0+0x10d8(1, ffbe37f4, 22a3d0, 4, 22a3b8, 0)
rb_call+0x404(96bc10, f31, 1, 156000, 21f420, 1)
rb_eval+0x2354(96bc10, 229da0, 0, 0, 156000, ffbe6990)
rb_eval+0x1cd8(96bc10, 229d28, 0, 156000, 229e18, 2f)
rb_call0+0x10d8(0, ffbe6964, 229d28, 0, 229e18, 0)
rb_call+0x404(96bc10, f31, 0, 156000, 21f3f0, 21f6c0)
rb_eval+0x1fe0(22a070, 233718, 19, 164800, 165000, 156000)
rb_eval+0x3118(22a070, 2334f0, ffffffff, 156000, 233778, 2f)
rb_call0+0x10d8(1, ffbe9ae4, 4, 4, 233778, 0)
rb_call+0x404(22a070, f31, 1, 156000, 224580, 1)
rb_eval+0x2354(22a070, 233d18, 46, 164800, 233d00, 0)
rb_eval+0x1128(22a070, 233d00, 18, 164800, 233d60, 233d60)
rb_eval+0x30c8(22a070, 233b98, ffffffff, 156000, 233e20, 2f)
rb_call0+0x10d8(1, ffbee1b4, 4, 4, 233e20, 0)
rb_call+0x404(22a070, f31, 1, 156000, 224718, 229f08)
rb_eval+0x1fe0(96bd30, 24d278, 19, 164800, 165000, 156000)
rb_eval+0x3118(96bd30, 24d260, 156000, 0, ffbf1e20, 2f)
rb_eval+0x9ec(96bd30, 24dad0, 1, 156000, 24db00, 2)
rb_call0+0x10d8(1, ffbf28a4, 24db30, 4, 24db00, 0)
rb_call+0x404(96bd30, f31, 1, 156000, 22f2d8, 2328d8)
rb_eval+0x1fe0(974160, 3e98b0, ffbf6fd0, 1010583f, 2020b, ffbf4b44)
rb_eval+0xe48(974160, 3e4648, 19, 164800, 165000, 156000)
rb_eval+0x3118(974160, 458820, 3, 156000, 3, 164800)
rb_call0+0x10d8(1, ffbf6fa4, 458be0, 2, 458bc8, 0)
rb_call+0x404(974160, f31, 3, 156000, 96c678, 1)
rb_eval+0x2354(974160, 461b68, 153c00, 4, 164800, 0)
block_pass+0x5c(974160, 461b80, ffbfba28, 461b80, 156000, 0)
rb_eval+0xc10(974160, 461b80, 19, 164800, 165000, 156000)
rb_eval+0x3118(974160, 462018, 1, 156000, 462048, 2)
rb_call0+0x10d8(1, ffbfb9fc, 462078, 4, 462048, 0)
rb_call+0x404(974160, f31, 1, 156000, 96c978, 553f98)
rb_eval+0x1fe0(19e330, 18b3b8, 0, 0, 156000, ffbffb88)
rb_eval+0x1cd8(19e330, 18b3a0, 19, 164800, 165000, 156000)
rb_eval+0x3118(19e330, 18b538, ffbffbb8, 156000, 165000, 153c00)
ruby_exec_internal+0xc0(153c00, 0, 0, 0, ffbffb90, 156000)
ruby_run+0x20(156000, 0, 0, 0, 156000, 0)
main+0x20(2, ffbffeac, ffbffeb8, 153800, ff0f00c0, ff0f0100)
_start+0x108(0, 0, 0, 0, 0, 0)

The only thing unusual about my system that I can think of offhand is 
that my hostname is "unknown".

If there's any other info I can provide from the core file please let me 
know (and also let me know how to get it - I'm not that familiar with 
debugging core files).

Regards,

Dan

In This Thread

Prev Next