pinba-engine does not compile under osx (homebrew) #40
Comments
|
+1, I have the same error, cannot compile pinba 1.1.0 |
|
Does this patch help: https://gist.github.com/17ee3f9cde526a4eae28 ? |
|
Yes it does, thanks! |
|
Are you using OS X too, by any chance? |
|
I can confirm it compiles now, but
Here is the output of lldb backtrace: I can provide additional information if required. |
|
Ok, what do you get with |
|
Here is the output: Thread 25 shows somethig related to pinba: |
|
Okay, so pthread_cancel() doesn't seem to break the eventloop on OS X. |
|
If you're using this MySQL instance for Pinba only (which I do recommend), then you can safely kill it with |
|
Okay. Thanks. Ping me later if you'll need some additional info/tests. |
|
Yes, it seems that this problem is inherited throughout all *BSD family. |
|
Does not help. Maybe I should recompile MySQL/pinba-engine with debugging support to help finding out the issue? |
|
Yes, recompiling MySQL and pinba with debug symbols would help to pinpoint the place where it's stuck, but I'm fairly sure I know where it is. |
|
Please try & see if branch devel_kevent_workaround fixes it for you. |
|
Not sure if I've compiled it properly, but it does not work yet. BTW, |
|
Hi, can we have the fix (for compiling) in master branch and release 1.1.1 first? Then we can keep investigating and fix the issue with shutting down later? |
|
I also have the same compilation problem on Linux i386: The initial patch proposed by @tony2001 is not available anymore. Does changing the type of str_hash to |
|
Here is the patch diff --git a/src/ha_pinba.cc b/src/ha_pinba.cc
index 8c71010..85193bb 100644
--- a/src/ha_pinba.cc
+++ b/src/ha_pinba.cc
@@ -2684,7 +2684,7 @@ int ha_pinba::read_next_row(unsigned char *buf, uint active_index, bool by_key)
str_hash = this_index[active_index].ival;
- ppvalue = JudyLNext(D->tag.name_index, &str_hash, NULL);
+ ppvalue = JudyLNext(D->tag.name_index, (Word_t *)&str_hash, NULL);
if (!ppvalue) {
ret = HA_ERR_END_OF_FILE;
goto failure;It works for me |
|
It would break on big endian architectures, I think. The value pointed for this_index[active_index].ival = str_hash;Maybe this is OK because this is consistent with what is done everywhere but since this is the only place where we do that, I think this is not. |
|
Hello, I am sending a patch for this package. With this patch package was successfully built on mips, mipsel, i386 on Debian. I have changed a type of str_hash in file src/ha_pinba.cc. --- pinba-engine-mysql-1.1.0.orig/src/ha_pinba.cc
+++ pinba-engine-mysql-1.1.0/src/ha_pinba.cc
@@ -2680,7 +2680,7 @@ int ha_pinba::read_next_row(unsigned cha
PPvoid_t ppvalue;
char name[PINBA_MAX_LINE_LEN] = {0};
pinba_tag *tag;
- uint64_t str_hash;
+ Word_t str_hash;
str_hash = this_index[active_index].ival;
Loking at a pinba-engine-mysql-1.1.0/src/ha_pinba.h one can notice that ival is of type size_t: typedef struct pinba_index_st { /* {{{ */
union {
size_t ival;
struct {
unsigned char *val;
uint len;
} str;
};
struct {
unsigned char *val;
uint len;
} subindex;
size_t position;
} pinba_index_st;
/* }}} */
However if we replace "uint64_t str_hash;" with "size_t str_hash;" on 32bit archs we have following problem: ha_pinba.cc:2687:59: error: invalid conversion from 'size_t* {aka unsigned int*}' to 'Word_t* {aka long unsigned int*}' [-fpermissive]
Taking a look at a Word_t one can find that: Same size as size_t but on 32bit one is "unsigned int" (size_t) and the other "long unsigned int" (Word_t) Taking this into consideration I have proposed a patch that I think it is safer than previously proposed patch that include type casting, which will probably fail during run-time on big-endian. Could you please consider including this patch? Thank you! Regards, |
|
The patch that Jurica had proposed worked for me. |
Here is a message I get when I'm trying to build pinba.
I have following source packages:
Seems like changing type of
str_hashtoWord_tsolves the issue but I'm not sure it's a correct way of fixing this. Maybe related with 64-bit platform?The text was updated successfully, but these errors were encountered: