青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

focus on linux, c/c++, lua

被delete難倒了

話說(shuō)我有一個(gè)結(jié)構(gòu)體如下:
struct stReplayData
{
    
int nDelay;        // 該數(shù)據(jù)在上一條消息之后的延遲,仿真(目前自定義1秒鐘)
    char* pData;    // 網(wǎng)絡(luò)數(shù)據(jù)包的內(nèi)容
    int nLen;        // 長(zhǎng)度

    stReplayData()
    
{
        nDelay 
= 0;
        nLen 
= 0;
        pData 
= NULL;
    }


    stReplayData(
int nLength)
    
{
        nDelay 
= 0;
        nLen 
= nLength;
        pData 
= NULL;
        
if (nLen > 0)
        
{
            pData 
= new char[nLen];
        }
                
    }


    stReplayData(
const stReplayData& src)
    
{
        
if (this == &src)
        
{
            
return;
        }

        
*this = src;
    }


    stReplayData
& operator = (const stReplayData& src)
    
{
        
if (this == &src)
        
{
            
return *this;
        }

        nDelay 
= src.nDelay;
        
if (pData != NULL)
        
{
            delete[] pData;
            pData 
= NULL;
        }
        
        nLen 
= src.nLen;
        
if (nLen > 0)
        
{
            pData 
= new char[nLen];        
            memcpy(pData, src.pData, nLen);
        }

        
return *this;
    }


    
~stReplayData()
    
{
        nDelay 
= 0;
        nLen 
= 0;
        
if (pData != NULL)
        
{
            delete[] pData;            
            pData 
= NULL;
        }
        
    }

}
;

我定義了一個(gè)vector<stReplayData*> m_vecReplay,然后new了一些stReplayData ,push_back這些指針進(jìn)去,最后程序釋放資源的時(shí)候,居然報(bào)調(diào)用釋放指針出錯(cuò)了,報(bào)的錯(cuò)就是平時(shí)見的很多的Heap上指針無(wú)效的錯(cuò)誤,基本上是說(shuō)stReplayData的析構(gòu)函數(shù)有問題,我了個(gè)擦,我怎么沒看出哪里有問題呢?

=====================================更多的代碼如下===============================================
我封裝了一個(gè)dll作為一個(gè)公共模塊,自然數(shù)據(jù)都會(huì)在這個(gè)公共模塊中存儲(chǔ),其中內(nèi)存數(shù)據(jù)的管理也會(huì)在這個(gè)dll中去做,也就是說(shuō),new和delete都會(huì)由這個(gè)dll自己去管理,
使用者只要去調(diào)接口,然后把需要存儲(chǔ)的數(shù)據(jù)地址傳給dll,讓dll自己去拷貝即可。模塊其實(shí)非常簡(jiǎn)單:
class CReplayManager : public IReplayManager
{
    typedef vector
<stReplayData*> VECREPLAY;
public:
    CReplayManager();
    
virtual ~CReplayManager();
    
virtual bool PushData(stReplayData* pData);
    
virtual stReplayData* PopData();
    
virtual stReplayData* GetTailData();
    
virtual void ClearData();
    
virtual void Release();    
private:
    VECREPLAY m_vecReplay;
}
;
這里還有個(gè)模版函數(shù),讓主程序朝dll寫數(shù)據(jù),
template<class M, class T>
void WriteReplay(M* m, const T& t)
{
    CWrite cw;
    cw.Write(t);
    stReplayData
* pReplay = new stReplayData(cw.GetLen());
    
if (pReplay != NULL)
    
{        
        pReplay
->nLen = cw.GetLen();
        memcpy(pReplay
->pData, cw.GetData(), cw.GetLen());
        m
->PushData(pReplay);
    }
        
}
另:在主程序里單獨(dú)的操作stReplayData是沒什么問題的,我也試驗(yàn)過。

=================================總結(jié)=================================
re: 被delete難倒了 2011-03-31 11:49 dizhu

問題就是SAFE_DELETE((*it)); 這個(gè)是在exe中new的,不能在dll中delete。

深入:
如果一個(gè)EXE調(diào)用一個(gè)DLL時(shí),用new和delete分配和釋放內(nèi)存為什么應(yīng)該放在同一個(gè)背景下的原因。得出的結(jié)論是,如果EXE和DLL有一個(gè)不是用動(dòng)態(tài)鏈接CRT庫(kù)(C   runtime   library)的方式使用CRT的話(Multi-threaded Debug DLL (/MDd)),或者是EXE和DLL動(dòng)態(tài)鏈接的CRT庫(kù)的版本不同時(shí),EXE和DLL將會(huì)各自擁有各自的堆空間,所以在DLL中new的東西務(wù)必在DLL中delete。

posted on 2011-03-30 17:29 zuhd 閱讀(2222) 評(píng)論(29)  編輯 收藏 引用 所屬分類: c/c++

評(píng)論

# re: 被delete難倒了 2011-03-30 17:36 namelij

你去看看vector里面的對(duì)象是怎么釋放的,就明白了  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-30 17:46 dizhu

貼下完整的代碼  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-30 17:50 Kevin Lynx

@dizhu
問題確實(shí)可能出在其他地方。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-30 17:55 千暮(zblc)

我按你說(shuō)的做了一遍 沒有報(bào)錯(cuò) - -bnr 你咋不把調(diào)用的代碼發(fā)下  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄] 2011-03-30 20:58 vincent

應(yīng)該還是也指著啊  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄] 2011-03-30 20:59 vincent

野指針……  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 00:50 Mensch88

1. 就這段代碼本身來(lái)說(shuō),有一個(gè)錯(cuò)誤:拷貝構(gòu)造函數(shù) stReplayData(const stReplayData& src) 里的指針pData沒有初始化!

2.stReplayData的析構(gòu)函數(shù)本身沒有問題。程序報(bào)錯(cuò)應(yīng)該是調(diào)用了兩次析構(gòu)函數(shù)造成的。
比如說(shuō),很有可能在使用時(shí)會(huì)犯這樣的錯(cuò)誤:
stReplayData data(otherdata);
vec.push_back(&data);
由于data本身會(huì)調(diào)用析構(gòu)函數(shù)delete pData,而delete vec里面的數(shù)據(jù)時(shí)也會(huì)調(diào)用data的析構(gòu)函數(shù),于是掛了。

  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 01:13 Mensch88

不好意思,第二點(diǎn)我說(shuō)得不大對(duì),因?yàn)闃侵髟谖鰳?gòu)函數(shù)里判斷了 if (pData != NULL), 并且之后會(huì)把pData=NULL,所以調(diào)用兩次析構(gòu)在單線程環(huán)境里不會(huì)問題。當(dāng)然多線程環(huán)境下就另說(shuō)了。

但我所陳述的問題依然是存在的,只是這不是因?yàn)閮纱挝鰳?gòu)造成,而是因?yàn)閐ata是棧上的數(shù)據(jù),不允許delete,所以掛了。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 09:14 zuhd

@Mensch88
1. 就這段代碼本身來(lái)說(shuō),有一個(gè)錯(cuò)誤:拷貝構(gòu)造函數(shù) stReplayData(const stReplayData& src) 里的指針pData沒有初始化!

拷貝構(gòu)造函數(shù)是調(diào)用operator =來(lái)著  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 09:36 dizhu

@Mensch88
vector里面保存的是指針,不會(huì)調(diào)用delete 的,不會(huì)存在你說(shuō)的兩次析構(gòu)函數(shù)調(diào)用  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 09:39 dizhu

@dizhu
如果樓主
stReplayData data(otherdata);
vec.push_back(&data);
然后還去delete vec里面的數(shù)據(jù),那就是樓主代碼寫的有問題,所以說(shuō)還是貼下完整的代碼,才能知道問題。但就這個(gè)stReplayData,還真看不出為什么會(huì)掛  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 10:13 zuhd

我更新了帖子 貼了更多的代碼 想嘗試的朋友 可以自己簡(jiǎn)單修改下即可  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:13 zuhd

問題我找到了,是我以前遇到的老問題
virtual bool PushData(stReplayData* pData);
這個(gè)接口設(shè)計(jì)有問題,dll的接口應(yīng)該用標(biāo)準(zhǔn)的c++類型,我只知道其然,不知道所以然,了解詳情的說(shuō)下  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:17 dizhu

@zuhd
重點(diǎn)把delete stReplayData 的代碼 和 CReplayManager 貼出來(lái)看下  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:22 zuhd

@dizhu
看了頭文件基本就能猜到代碼了吧 中規(guī)中矩的容器操作代碼而已

另:我在gcc中的頭文件大量的使用了自定義的類,貌似沒發(fā)現(xiàn)過什么問題,怎么用vc上來(lái)就碰到這個(gè),是巧合還是必然?腫么辦?有沒有,有沒有?  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:24 dizhu

@zuhd
我比較關(guān)心CReplayManager 的Release 以及 ClearData 的實(shí)現(xiàn)。是不是在這里面delete stReplayData 了??  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:41 zuhd

void CReplayManager::ClearData()
{
VECREPLAY::iterator it = m_vecReplay.begin();
for (; it != m_vecReplay.end(); it++)
{
SAFE_DELETE((*it));
}
m_vecReplay.clear();
}  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:49 dizhu

@zuhd
void CReplayManager::ClearData()
{
VECREPLAY::iterator it = m_vecReplay.begin();
for (; it != m_vecReplay.end(); it++)
{
SAFE_DELETE((*it));
}
m_vecReplay.clear();
}
問題就是SAFE_DELETE((*it)); 這個(gè)是在exe中new的,不能在dll中delete。
原因:http://blog.csdn.net/blz_wowar/archive/2008/03/13/2176536.aspx  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 11:56 zuhd

@dizhu
在exe中new,不能在dll中delete的?
exe和dll用的是同一個(gè)堆棧空間的,  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 17:48 Mensch88

zuhd@zuhd
--拷貝構(gòu)造函數(shù)是調(diào)用operator =來(lái)著

拷貝構(gòu)造函數(shù)是調(diào)用了operator=,但是operator=里面會(huì)判斷pData是否為NULL:
if (pData != NULL)
{
delete[] pData;
pData = NULL;
}
必須注意的是,這時(shí)pData還沒有被初始化。這樣就會(huì)執(zhí)行 delete[] pData;
從而出錯(cuò)。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 17:55 Mensch88

@dizhu
--然后還去delete vec里面的數(shù)據(jù),那就是樓主代碼寫的有問題,所以說(shuō)還是貼下完整的代碼,才能知道問題。但就這個(gè)stReplayData,還真看不出為什么會(huì)掛

因?yàn)闃侵髡f(shuō)了vec里面是一些new出來(lái)的指針,而之后程序釋放資源時(shí)報(bào)錯(cuò),于是我估計(jì)樓主所說(shuō)的程序釋放資源就是指將vec里面的指針delete。
樓主后來(lái)的代碼也證實(shí)了我的猜測(cè)。

  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 18:31 Mensch88

樓主的問題算是CRT的bug么?
Linux下測(cè)試,無(wú)論是靜態(tài)還是動(dòng)態(tài)鏈接都沒發(fā)現(xiàn)這種問題。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-03-31 23:54 flyinghearts


建議還是用 vector<char> 或 string 代替 char*

stReplayData 設(shè)計(jì)得有點(diǎn)問題,
一般都是 在拷貝構(gòu)造函數(shù)中進(jìn)行分配新內(nèi)存處理, 然后在賦值函數(shù)中調(diào)用拷貝構(gòu)造函數(shù),構(gòu)造一個(gè)臨時(shí)類對(duì)像,與原類對(duì)象進(jìn)行交換。

你的實(shí)現(xiàn)剛好相反,拷貝構(gòu)造函數(shù)調(diào)用 賦值函數(shù),但 賦值函數(shù)中用到的 nlen 和 pdata兩個(gè)值都未初始化,UB行為。

實(shí)際上,這兩個(gè)判斷都是可以去掉的,new char[0] 是有意義的,沒必要對(duì) nlen進(jìn)行判斷
delete[] p 當(dāng)p是空指針時(shí),沒有任何效果,因此沒必要對(duì)pdata進(jìn)行判斷

拷貝構(gòu)造函數(shù)中 對(duì)指針的判斷 也是多余的。
另外,要先分配新內(nèi)存,再釋放舊內(nèi)存,保證 異常安全。

  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-04-01 09:44 zuhd

@flyinghearts
那個(gè)拷貝構(gòu)造函數(shù)確實(shí)有點(diǎn)問題,以前拷貝構(gòu)造函數(shù)調(diào)用=寫順手了,沒發(fā)現(xiàn)有內(nèi)存操作的這么寫有這個(gè)陷阱,改了一下:
stReplayData(const stReplayData& src)
{
if (this == &src)
{
return;
}
nDelay = src.nDelay;
nLen = src.nLen;
pData = new char[nLen];
if (pData != NULL)
{
memcpy(pData, src.pData, nLen);
}
}

stReplayData& operator = (const stReplayData& src)
{
if (this == &src)
{
return *this;
}
nDelay = src.nDelay;
nLen = src.nLen;
if (pData != NULL)
{
delete[] pData;
pData = NULL;
}
pData = new char[nLen];
if (pData != NULL)
{
memcpy(pData, src.pData, nLen);
}
return *this;
}

至于你說(shuō)的:
另外,要先分配新內(nèi)存,再釋放舊內(nèi)存,保證 異常安全。
好像我一直都是先delete 再new ,可能一直懶得用個(gè)臨時(shí)的指針來(lái)保存pData吧,不過你這么說(shuō)的道理是??  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄] 2011-04-01 11:32 hdqqq

如果樓主使用 /mt 編譯,dll啟動(dòng)時(shí)使用自己的堆, 在主程序中new 出來(lái)的對(duì)象,再通過指針傳給dll,然后在dll中釋放,會(huì)產(chǎn)生錯(cuò)誤,主程序和dll使用不同的堆。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄] 2011-04-01 14:39 楊粼波

把struct改為class,然后把數(shù)據(jù)private,測(cè)試一次看看。排除客戶代碼應(yīng)用上的錯(cuò)誤。

當(dāng)然了,也有可能在調(diào)用的時(shí)候,被其他地方的錯(cuò)誤牽連導(dǎo)致這個(gè)struct的數(shù)據(jù)被損壞。

如果牽扯到DLL的話,那有可能是exe和dll兩者之間的版本不一致所導(dǎo)致,DLL的導(dǎo)出地址是用的一個(gè),卻不想exe用了另外一個(gè),所以發(fā)生錯(cuò)誤,這是有可能發(fā)生的。用VS的編譯器,特別是2003,你需要依照以下步驟重編譯:清理全部(包括dll和exe)->重編。  回復(fù)  更多評(píng)論   

# re: 被delete難倒了[未登錄] 2011-04-01 15:40 楊粼波

http://blog.csdn.net/ssli/archive/2009/06/16/4272484.aspx  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-04-01 23:30 flyinghearts

 
class stReplayData
{
  
int nDelay;     // 該數(shù)據(jù)在上一條消息之后的延遲,仿真(目前自定義1秒鐘)
  size_t nLen;  // 長(zhǎng)度
  char* pData;    // 網(wǎng)絡(luò)數(shù)據(jù)包的內(nèi)容
  
public:  
  stReplayData(size_t nLength 
= 0): nDelay(0), 
      nLen(nLength), pData(
new char[nLength]()) {}
  
  
~stReplayData() { delete[] pData; }
  
  stReplayData(
const stReplayData& src):  nDelay(src.nDelay),
      nLen(src.nLen), pData(
new char[src.nLen]) 
  {
    memcpy(pData, src.pData, nLen);  
  }
    
  stReplayData
& operator=(stReplayData tmp) //構(gòu)建一個(gè)臨時(shí)對(duì)像
  {
    nDelay 
= tmp.nDelay;
    nLen 
= tmp.nLen;
    std::swap(pData, tmp.pData);
    
return *this;
  }
};

 
可參考以前寫的這篇文章:
http://blog.csdn.net/flyinghearts/archive/2010/06/16/5673089.aspx
  回復(fù)  更多評(píng)論   

# re: 被delete難倒了 2011-04-02 11:42 tingya

涉及到跨模塊內(nèi)存使用的問題,應(yīng)該遵守誰(shuí)使用,誰(shuí)釋放  回復(fù)  更多評(píng)論   

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美国产91| 欧美 日韩 国产 一区| 久久免费视频观看| 欧美三级资源在线| 亚洲国产精品va在线看黑人动漫| 亚洲一区二区视频在线| 亚洲大黄网站| 久久综合色播五月| 在线看欧美日韩| 久久视频在线视频| 欧美中文字幕在线播放| 国产精品久久亚洲7777| 亚洲免费在线视频| 亚洲手机成人高清视频| 国产精品日韩精品| 欧美尤物一区| 欧美中文字幕视频| 亚洲国产影院| 99国产精品99久久久久久粉嫩| 欧美日韩三级一区二区| 亚洲一区精彩视频| 亚洲砖区区免费| 国内成人精品视频| 亚洲电影专区| 国产精品v亚洲精品v日韩精品| 亚洲一区制服诱惑| 午夜在线电影亚洲一区| 国产一区二区三区直播精品电影| 久久色在线播放| 欧美精品乱码久久久久久按摩| 99视频一区二区| 亚洲欧美日韩国产综合| 一区二区三区在线视频免费观看| 久久久久久久网| 免费观看日韩av| 免费观看亚洲视频大全| 一本色道久久综合亚洲精品婷婷| 午夜精品视频在线| 亚洲欧洲精品一区二区三区波多野1战4| 亚洲黄色精品| 国产午夜精品一区二区三区欧美 | 国产午夜精品一区二区三区欧美 | 亚洲国产成人av| 国产精品推荐精品| 91久久精品美女高潮| 国产亚洲一区二区在线观看| 亚洲国内高清视频| 精品成人一区二区| 亚洲欧美激情视频| 亚洲尤物在线视频观看| 欧美大片网址| 欧美成人免费小视频| 狠狠色综合色区| 中文在线一区| 在线亚洲激情| 欧美激情1区| 欧美激情一区在线观看| 狠狠色狠狠色综合日日小说| 亚洲欧美国产毛片在线| 亚洲自拍偷拍视频| 欧美午夜精品久久久久久孕妇| 亚洲国产欧美国产综合一区| 亚洲大片精品永久免费| 久久人人97超碰精品888 | 亚洲欧美中文日韩v在线观看| 一本色道综合亚洲| 欧美日韩国产精品自在自线| 亚洲人永久免费| 一区二区高清在线| 欧美性大战久久久久久久| 一二三四社区欧美黄| 欧美一区三区三区高中清蜜桃| 国产精品永久免费视频| 午夜精品久久久久久久| 国产一区二区三区无遮挡| 久久久在线视频| 亚洲高清精品中出| 夜夜嗨av一区二区三区中文字幕| 欧美日韩高清在线播放| 亚洲欧美清纯在线制服| 麻豆精品视频在线观看视频| 亚洲国产综合在线看不卡| 国产精品yjizz| 久久久久久久久久看片| 亚洲精品国产精品国产自| 亚洲欧美日韩在线不卡| 激情六月综合| 国产精品不卡在线| 久久亚洲精品中文字幕冲田杏梨| 亚洲欧洲日本国产| 午夜欧美大尺度福利影院在线看| 韩国v欧美v日本v亚洲v| 欧美激情一区三区| 欧美亚洲一级片| 一本到12不卡视频在线dvd | 激情文学综合丁香| 欧美日韩免费区域视频在线观看| 午夜一区二区三视频在线观看| 欧美激情精品久久久久久| 午夜天堂精品久久久久| 亚洲美女色禁图| 1000部精品久久久久久久久| 国产精品一级二级三级| 欧美日韩久久| 欧美激情久久久久| 欧美+日本+国产+在线a∨观看| 欧美在线视频播放| 亚洲私拍自拍| 亚洲电影自拍| 欧美激情视频一区二区三区在线播放| 欧美一级久久久久久久大片| 亚洲视频免费看| 亚洲免费高清| 99视频精品在线| 99精品欧美一区二区三区综合在线| 精东粉嫩av免费一区二区三区| 国产综合色在线视频区| 国产小视频国产精品| 国产女精品视频网站免费| 欧美精品成人| 国产精品免费一区豆花| 国产精品一区亚洲| 国产欧美日本一区二区三区| 国产视频观看一区| 狠狠色综合日日| 欧美国产在线视频| 欧美精品v国产精品v日韩精品| 麻豆精品91| 欧美激情亚洲另类| 国产精品国产三级国产aⅴ入口| 国产精品自拍网站| 狠狠久久综合婷婷不卡| 亚洲国产小视频在线观看| 一本久久a久久免费精品不卡| 亚洲免费在线电影| 久久综合给合久久狠狠狠97色69| 欧美r片在线| 日韩一级精品视频在线观看| 先锋影音一区二区三区| 女同一区二区| 国产日韩欧美一区| 亚洲精品一区在线| 欧美亚洲视频一区二区| 欧美大片在线影院| 亚洲影视在线播放| 免费观看国产成人| 国产视频一区免费看| 99精品福利视频| 小黄鸭精品aⅴ导航网站入口| 国产一区二区日韩精品欧美精品| 精品999成人| 久久成年人视频| 亚洲视频每日更新| 欧美区在线观看| 亚洲人成网站在线播| 榴莲视频成人在线观看| 亚洲日本免费| 久久精品国产69国产精品亚洲| 欧美午夜寂寞影院| 一区二区三区久久久| 亚洲第一页在线| 裸体素人女欧美日韩| 一区二区在线观看视频在线观看| 欧美一区二区三区日韩| 一本色道久久综合亚洲精品不卡 | 久久综合电影| 久久婷婷蜜乳一本欲蜜臀| 经典三级久久| 欧美大秀在线观看| 欧美激情一区二区三区四区| 亚洲精品欧美专区| 夜色激情一区二区| 国产伦精品一区二区三区免费 | 亚洲婷婷免费| 亚洲网友自拍| 国产亚洲欧美色| 欧美成人69av| 欧美精品在线网站| 欧美日韩久久精品| 亚洲视频一区二区| 先锋影音一区二区三区| 亚洲激情一区二区| 日韩一区二区精品葵司在线| 国产精品福利在线观看| 久久成人这里只有精品| 美女图片一区二区| 亚久久调教视频| 嫩草国产精品入口| 午夜精品成人在线视频| 蜜桃av噜噜一区二区三区| 亚洲天堂男人| 久久亚洲高清| 午夜精品在线看| 欧美国产日本高清在线| 欧美中文字幕| 欧美特黄视频| 亚洲国产精品高清久久久| 国产亚洲欧美另类一区二区三区| 亚洲乱码国产乱码精品精| 狠色狠色综合久久|