Alist v3.43.0 , 百度网盘上传程序闪退，回滚到 v3.42.0 后正常

[wnbh]

Please make sure of the following things

• I have read the documentation.
  我已经阅读了文档。

• I'm sure there are no duplicate issues or discussions.
  我确定没有重复的issue或讨论。

• I'm sure it's due to AList and not something else(such as Network ,Dependencies or Operational).
  我确定是AList的问题，而不是其他原因（例如网络，依赖或操作）。

• I'm sure this issue is not fixed in the latest version.
  我确定这个问题在最新版本中没有被修复。

AList Version / AList 版本

v3.43.0

Driver used / 使用的存储驱动

百度网盘

Describe the bug / 问题描述

Alist v3.43.0 , 百度网盘上传程序闪退，回滚到 v3.42.0 后正常。提示如图示

Reproduction / 复现链接

随时随地复现

Config / 配置

不会提供

Logs / 日志

No response

[petercat-assistant]

感谢您提供详细的信息。根据您的描述，Alist v3.43.0 在使用百度网盘上传时出现了程序闪退的问题，而回滚到 v3.42.0 后问题消失。这可能是由于新版本中的某些更改导致的兼容性问题。

为了帮助解决这个问题，您可以尝试以下步骤：

1. 检查更新日志：查看 v3.43.0 的更新日志，看看是否有关于百度网盘或上传功能的更改。

2. 提供更多日志信息：如果可能，请尝试获取更多的日志信息，这将有助于开发者更好地诊断问题。

3. 测试其他驱动：如果您有其他存储驱动可用，尝试使用其他驱动进行上传，看看是否也会出现类似的问题。

4. 反馈给开发者：如果问题持续存在，建议将此问题反馈给开发者，以便他们进行修复。

如果您愿意，我可以帮助您在 GitHub 上创建一个问题报告，以便开发者能够更快地看到并解决这个问题。请告诉我您的决定。

🪧 Tips

For further assistance, please describe your question in the comments and @petercat-assistant to start a conversation with me.

[ljcbaby]

看一下日志或者命令行跑起来看一下报错在哪，3.43 baidu_netdisk 应该只有我交的的两个pr有改动，但是我（包括我周围一圈）用起来都没问题

[ljcbaby]

另外问几个最基本的问题：上传文件大小，挂载百度网盘的参数，你账号的vip级别

参数可以把这块截图看看

[wnbh]

另外问几个最基本的问题：上传文件大小，挂载百度网盘的参数，你账号的vip级别

参数可以把这块截图看看

如图，每次都是在一个文件要上传完的时候报错，我没有VIP，文件4G左右，之前的版本就没有这个问题，参数对比之前的版本也没有任何的变动

[ljcbaby]

普通用户单个上传文件大小上限为4GB

你可能要严格确定一下文件大小有没有超。图上warn里的分片号可以一起给一下吗

崩溃看样子是个信号量重复释放的问题，在 #7972 的改动重试逻辑覆盖应该会涉及这段代码，但是没有实质性更改。

[wnbh]

普通用户单个上传文件大小上限为4GB

你可能要严格确定一下文件大小有没有超。图上warn里的分片号可以一起给一下吗

崩溃看样子是个信号量重复释放的问题，在 #7972 的改动重试逻辑覆盖应该会涉及这段代码，但是没有实质性更改。

2025/03/23 10:12:10.357571 WARN RESTY Post "https://d.pcs.baidu.com/rest/2.0/pcs/superfile2?access_token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&method=upload&partseq=1&path=%2F141+%E5%8E%BB%E6%A8%AA%E7%BA%B9.mp4.z01&type=tmpfile&uploadid=P1-MTAuMTQ2LjE2Mi4yNzoxNzQyNzI0NzAwOjg4MTM3MzAxMjY2ODcxNDkzOTY%3D": context deadline exceeded (Client.Timeout exceeded while awaiting headers), Attempt 1
panic: semaphore: released more than held

[ljcbaby]

#7948 @KirCute 看看

[KirCute]

#7948 @KirCute 看看

看起来确实是我的问题，但我没看懂为什么会出这个问题，semaphore 是在 L269 获取的，在 L278 释放的，按理来说每获取一个就会创建一个上传线程，每个上传线程结束时一定会释放一个，应该不会出现释放比获取多的问题。会不会是这个 errgroup 有什么我不知道的重试机制。

alist/drivers/baidu_netdisk/driver.go

Lines 263 to 281 in 32890da

	threadG, upCtx := errgroup.NewGroupWithContext(ctx, d.uploadThread)
	sem := semaphore.NewWeighted(3)
	for i, partseq := range precreateResp.BlockList {
	if utils.IsCanceled(upCtx) {
	break
	}
	if err = sem.Acquire(ctx, 1); err != nil {
	break
	}
	i, partseq, offset, byteSize := i, partseq, int64(partseq)*sliceSize, sliceSize
	if partseq+1 == count {
	byteSize = lastBlockSize
	}
	threadG.Go(func(ctx context.Context) error {
	defer sem.Release(1)
	params := map[string]string{
	"method": "upload",
	"access_token": d.AccessToken,

[ljcbaby]

#7948 @KirCute 看看

看起来确实是我的问题，但我没看懂为什么会出这个问题，semaphore 是在 L269 获取的，在 L278 释放的，按理来说每获取一个就会创建一个上传线程，每个上传线程结束时一定会释放一个，应该不会出现释放比获取多的问题。会不会是这个 errgroup 有什么我不知道的重试机制。

alist/drivers/baidu_netdisk/driver.go

Lines 263 to 281 in 32890da

threadG, upCtx := errgroup.NewGroupWithContext(ctx, d.uploadThread)
sem := semaphore.NewWeighted(3)
for i, partseq := range precreateResp.BlockList {
if utils.IsCanceled(upCtx) {
break
}
if err = sem.Acquire(ctx, 1); err != nil {
break
}

i, partseq, offset, byteSize := i, partseq, int64(partseq)*sliceSize, sliceSize
if partseq+1 == count {
byteSize = lastBlockSize
}
threadG.Go(func(ctx context.Context) error {
defer sem.Release(1)
params := map[string]string{
"method": "upload",
"access_token": d.AccessToken,

#7972 里我把 errgroup 的重试给撤了的，现在应该只靠 RestyClient 重试

（没撤掉的话好像炸的更严重，已经是歪打正着修了一波了）

[KirCute]

（没撤掉的话好像炸的更严重，已经是歪打正着修了一波了）

要不我把获取信号量放到线程函数里面算了，大不了就是有一堆线程在空等待，总比直接炸了好

[ljcbaby]

	DefaultAttempts      = uint(10)
	DefaultDelay         = 100 * time.Millisecond
	DefaultMaxJitter     = 100 * time.Millisecond
	DefaultOnRetry       = func(n uint, err error) {}
	DefaultRetryIf       = IsRecoverable
	DefaultDelayType     = CombineDelay(BackOffDelay, RandomDelay)
	DefaultLastErrorOnly = false
	DefaultContext       = context.Background()

认真看了一下，是我改动造成的问题。

可能要考虑一下在 pkg/errgroup 覆盖一下 retry 的默认值

[ljcbaby]

应该说改不改都会有问题，只是改了放大了问题

[KirCute]

应该说改不改都会有问题，只是改了放大了问题

我觉得还是应该让分片上传可以重试比较好，要不我还是把获取信号量放到线程里吧

[ljcbaby]

应该说改不改都会有问题，只是改了放大了问题

我觉得还是应该让分片上传可以重试比较好，要不我还是把获取信号量放到线程里吧

我改是因为有两层重试，一层 RestyClient 一层 errgroup 这样看日志的时候报错会有点懵。

两层都留的话，外层丢异步重试可能是合理的。

我的pr肯定是要改一下的了，你看看你的是不是用到信号量的地方也要检查一下从重试。

[ljcbaby]

另外问几个最基本的问题：上传文件大小，挂载百度网盘的参数，你账号的vip级别
参数可以把这块截图看看

如图，每次都是在一个文件要上传完的时候报错，我没有VIP，文件4G左右，之前的版本就没有这个问题，参数对比之前的版本也没有任何的变动

顺便，建议你把上传线程调小，你现在上传一个文件要稳定得有 4*32/30 = 4.27 MB/s 的带宽

[wnbh]

另外问几个最基本的问题：上传文件大小，挂载百度网盘的参数，你账号的vip级别
参数可以把这块截图看看

如图，每次都是在一个文件要上传完的时候报错，我没有VIP，文件4G左右，之前的版本就没有这个问题，参数对比之前的版本也没有任何的变动

顺便，建议你把上传线程调小，你现在上传一个文件要稳定得有 4*32/30 = 4.27 MB/s 的带宽

带宽是完全够的，上个版本拉满，同时上传五个文件，线程数也是32，也没出现这个问题。我好像也试过把线程调为1，还是会闪退。