Hypertable Development Google Group

Re: Segmentation fault in memcpy()

2008-10-09T16:59:18Z

Hypertable uses dns very lightly mostly at init stage. I don't know if
you've used libadns before, the interface is quite hairy. The easiest
fix would be an #ifdef for linux etc. As it turns out, gethostbyname
is actually thread safe on recent OS X (Darwin. The manual is
outdated) using thread local storage.

Re: [hypertable-dev] Re: Segmentation fault in memcpy()

2008-10-09T15:36:21Z

perhaps libadns ?
[link]
Mateusz

Re: [hypertable-dev] Re: Segmentation fault in memcpy()

2008-10-09T14:58:58Z

I believe I've found the problem: In function InetAddr::initialize(),
the non-reentrant function gethostbyname() is used unprotected. I've
replaced it with gethostbyname_r() and tested 3 more times, the
problem didn't occur any more.
According to its manpage, gethostbyname_r() seems to be only available

Re: [hypertable-dev] Connecting to hyperspace?

2008-10-05T15:46:58Z

Hi Mateusz,
Try the attached source file. It works with Hypertable 0.9.0.10.
src/cc/tools/hyperspace/hypers pace.cc can be used as sample code, too.
Donald

Connecting to hyperspace?

2008-10-05T14:33:26Z

Hi list readers,
I'm curious if there's an easy way of connecting to the Hyperspace
without establishing a "full" Hypertable connection? The documentation
mentions a Hyperspace::Session object but it's constructor asks for
Comm object as well as property file path. Is there an effortless way
of getting Comm object and not instantiating Hypertable::Client ?

On Vacation in October

2008-10-02T14:50:27Z

I'll be leaving on vacation today and will be gone until October 29th. I'll
be offline the whole time, so you won't hear from me until I get back. Have
a great October!
- Doug

0.9.0.11 patch release available

2008-10-01T02:28:51Z

Patch release 0.9.0.11 <[link]> has been released and is now
available for download at [link].
NOTE: You may have to hit the refresh button on you browser to get the
latest file
Version 0.9.0.11:
(2008-09-30)
* Fixed problem with commit log garbage collection

Re: python bindings to hypertable

2008-09-25T11:53:12Z

Trying to build HypertableBindings.cc
cmake -DBUILD_SHARED_LIBS=ON /path/to/PythonBinding/
make

<.....>
/usr/local/src/hypertable-0.9. 0.10-alpha/contrib/cc/PythonBi nding/
HypertableBindings.h:166: instantiated from here
/usr/include/boost/noncopyable .hpp:27: error:
‘boost::noncopyable_::noncopya ble::noncopyable(const

Re: [hypertable-dev] Re: Segmentation fault in memcpy()

2008-09-25T00:58:43Z

That might explain how the program generated a segfault while running, but
dumps a good core image. Can you isolate the differences with this current
setup and your previous runs where you did not encounter the problem? Let
us know what changed from your previous runs where you did not encounter
these problems and this one. Did you update the software? Are these

Re: [hypertable-dev] Re: Segmentation fault in memcpy()

2008-09-24T16:50:33Z

Yes, they are using ECC memory. Do you mean there maybe a hardware
error or something?
Donald

Re: Major overhaul

2008-09-24T02:15:43Z

We've also upgraded to Hadoop 0.18.1 in one of the recent checkins.
- Doug

Major overhaul

2008-09-24T00:57:54Z

I just finished a pretty major overhaul of the code. You can see the commit
at
[link]
The following two changes went in:
1. Compactions now happen by freezing the cell cache and installing a new
empty one. When the compaction completes, the frozen cell cache gets thrown

Re: [hypertable-dev] Re: Segmentation fault in memcpy()

2008-09-24T00:04:20Z

Hi Donald,
Can you verify that these machines are installed with ECC memory?
- Doug

Re: [hypertable-dev] Re: Segmentation fault in memcpy()

2008-09-23T15:24:44Z

Hi Doug,
I know this command, you've taught me many times :)
I did examine other threads, but find nothing unusual. Full story followed:
$ gdb -c core.333 hypertable/0.9.0.10/bin/Hypert able.RangeServer
[...]
Core was generated by
`/home/ht4/hypertable/0.9.0.10 /bin/Hypertable.RangeServer
--pidfile=/home/ht4/hy'.

Re: [hypertable-dev] Segmentation fault in memcpy()

2008-09-23T14:55:23Z

Hi Donald,
The segfault may have happened in a different thread. To view the stack
traces for all threads, issue this command:
(gdb) thread apply all where
You can then switch threads with the 'thread <tid>' command. Try examining
the other threads to see if they were the cause.
- Doug