根据内存布局定位的一个fastdfs坑

在使用fastdfs时，编写数据上传代码时，遇到一个坑。最终根据指针对应的内存布局定位到一个其client API的一个坑，值得记录一下。
具体是在 tracker_connect_server() 这个API上，其是一个宏，具体定义如下

 #define tracker_connect_server(pTrackerServer, err_no) \
 tracker_connect_server_ex(pTrackerServer, g_fdfs_connect_timeout, err_no)

tracker_connect_server_exs 声明如下

 ConnectionInfo *tracker_connect_server_ex(ConnectionInfo *pTrackerServer, const int connect_timeout, int *err_no);

在tracker_proto.c中实现，其返回值将在后面数据上传操作中的链接句柄。

当配置不使用连接池的时候，连接操作成功时，会将 pTrackerServer 参数原样返回，一般使用者会习惯性地保存该指针句柄供后用。我自己仿照着范例代码使用，结果就掉坑里了。

如此设计实现，就极易产生勿用，如下：
当 tracker_connect_server_ex() 的 pTrackerServer 参数传递的对象，后续被销毁之后，用户是不知道刚才通过返回值拿到的指针句柄指向的对象是已经不复存在的。
后续继续使用该已经失效的指针句柄进行数据上传操作时，结果就不可预知了。

实际上在其工程test目录下的范例代码 dfs_func.c 中， upload_file() 函数 pTrackerServer 参数就传递了一个栈上的临时对象，但其在 upload_file() 中立即使用返回值的指针句柄调用 storage_upload_by_filebuff1() 进行数据上传，所以对应返回值指针句柄指向的对象，在此过程中都一直有效，而没有造成问题。

但自己就没有这么幸运了。我类似地仿照 upload_file() 给 tracker_connect_server() 传递了一个栈上的临时对象时，拿到其返回值做保存之后，将从当前调用函数返回了，
后续使用刚才保存的指针句柄调用 storage_do_upload_file1() 进行数据上传操作，总是出现下面的错误打印
[2016-03-05 17:46:26] ERROR - file: storage_client.c, line: 933, send data to storage server :0 fail, errno: 88, error info: Socket operation on non-socket

于是就开始了一番debug，可从 tracker_connect_server() 调用返回的地方，一路确认到调用 storage_do_upload_file1() 的地方，该指针句柄值都没有发生变化，但其指向的内存却被异常地清零了，一时见鬼了！后来在 gdb 中对给 storage_do_upload_file1() 传递的前两个参数值 print 了一把，发现了一点端倪，如下

 (gdb) p  ((struct fastdfs_priv*)&dfs[1])->tracker_conn
 $4 = (ConnectionInfo *) 0x613150
 (gdb) p  ((struct fastdfs_priv*)&dfs[1])->storage_conn
 $5 = (ConnectionInfo *) 0x7fffffffe4e0
 (gdb) 

根据地址区间，很明显 tracker_conn 指向的内存在堆上，而 storage_conn 指向的内存在栈里！这就奇了怪，storage_conn 值源头是来自 tracker_connect_server() 啊，难道其给我返回了一个栈上的临时对象地址？其作者应该不会犯这种弱智错误吧？去看了 tracker_connect_server_ex() 的代码之后，顿时吐血！太坑了吧！作者自己难道没想过上面的这些问题么？而且还在范例代码中，这么用？明显误导人么？？！！！

知道原因之后，立即将 tracker_connect_server() 第一个参数传递的对象改为不是临时的后，问题解决！

刚才的问题，之所以能发现突破点，还是根据指针值对应的内存布局来确定的。这又一次说明了内存等的相关的基础知识是非常重要的！！！